CAP Operator

CAPApplication

Mon, 01 Jan 0001 00:00:00 +0000

Here’s an example of a fully configured CAPApplication:

apiVersion: sme.sap.com/v1alpha2
kind: CAPApplication
metadata:
 name: cap-app
 namespace: cap-ns
spec:
 btp:
 services:
 - class: xsuaa
 name: cap-uaa
 secret: cap-uaa-bind
 - class: saas-registry
 name: cap-saas-reg
 secret: cap-saas-reg-bind
 - class: service-manager
 name: cap-service-manager
 secret: cap-svc-man-bind
 - class: destination
 name: cap-destination
 secret: cap-bem-02-dest-bind
 - class: html5-apps-repo
 name: cap-html5-repo-host
 secret: cap-html5-repo-bind
 - class: html5-apps-repo
 name: cap-html5-repo-runtime
 secret: cap-html5-rt-bind
 - class: some-content-service
 name: cap-some-content-service
 secret: cap-some-content-service-bind
 - class: business-logging
 name: cap-business-logging
 secret: cap-business-logging-bind
 btpAppName: cap-app
 domainRefs:
 - kind: Domain
 name: cap-app-01-primary
 - kind: ClusterDomain
 name: common-external-domain
 providerSubaccountId: 7a49218f-c750-4e1f-a248-7f1cefa13010

The btp.services array specifies all SAP BTP service instances and their corresponding Kubernetes Secrets (containing credentials) required by the application. These service instances are assumed to exist in the provider subaccount. You can use operators such as cf-service-operator or sap-btp-service-operator to declaratively create these service instances and their credentials as Kubernetes resources.

Controller

Mon, 01 Jan 0001 00:00:00 +0000

The CAP controller uses client-go from Kubernetes, which provides the tools and utilities needed to interact with the Kubernetes API server and manage the custom resources defined by CAP Operator.

The controller uses Informers to watch certain resources and invokes registered event handlers when these resources are modified. To streamline the processing of such notifications, rate-limiting queues are implemented that store changes and allow processing of items in independent reconciliation threads (goroutines). This design enables sequential processing of changed items and avoids conflicts.

Custom DNS Templates

Mon, 01 Jan 0001 00:00:00 +0000

When dnsMode is set to Custom, the operator creates DNS entries according to the dnsTemplates field instead of the fixed patterns used by Wildcard and Subdomain modes. This lets you generate multiple DNS records per domain, map subdomains to external names, or combine wildcard and per-subdomain entries in one resource.

Prerequisite

DNS entry creation requires the Gardener external-dns-management controller. When using the Kubernetes DNS manager, dnsMode is ignored and no DNS entries are created regardless of the mode chosen.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Optional Configuration

Enable Service Monitors for metrics

To enable monitoring via metrics emitted by CAP Operator components, set the following value:
```
monitoring:
 enabled: true # <-- enables creation of service monitors for metrics emitted by CAP Operator components
```
To enable detailed operational metrics for the controller:
```
controller:
 detailedOperationalMetrics: true
```
Set up Prometheus integration for Version Monitoring

To use the Version Monitoring feature, provide a Prometheus server URL to the CAP Operator. When installing with the Helm chart, specify the following values:
```
controller:
 versionMonitoring:
 prometheusAddress: "http://prometheus-operated.monitoring.svc.cluster.local:9090" # <-- example of a Prometheus server running inside the same cluster
 promClientAcquireRetryDelay: "2h"
 metricsEvaluationInterval: "30m" # <-- interval at which version metrics are evaluated
```
On startup, the controller attempts to connect to the Prometheus server and fetch runtime information to verify the connection. If the connection fails, the controller retries after the delay specified in controller.versionMonitoring.promClientAcquireRetryDelay. See default values here.
Note
- When connecting the controller to a Prometheus server running inside the cluster, ensure that the NetworkPolicy resources required for connecting to the service in the Prometheus namespace are also created.
- If the Prometheus service is configured to use TLS, mount the relevant CA root certificates as volumes on the controller.

Configure maximum concurrent reconciles

The controller reconciles each resource type with a built-in default concurrency. To override these defaults, configure the values explicitly:

controller:
 maxConcurrentReconciles:
 capApplication: "1" # default: 1
 capApplicationVersion: "3" # default: 3
 capTenant: "10" # default: 10
 capTenantOperation: "10" # default: 10
 domain: "1" # default: 1
 clusterDomain: "1" # default: 1

Configure controller client rate limiting

To control the rate at which the controller client sends requests to the Kubernetes API server, configure the QPS (queries per second) and burst values:
```
controller:
 clientRateLimiting:
 qps: "20" # <-- maximum queries per second
 burst: "30" # <-- maximum burst for throttle
```
Configure controller rollout delay

To introduce a delay before the controller rolls out workloads of relevant application versions on credential update (e.g. to allow a safe rollout window), set the rollout delay:
```
controller:
 rolloutDelay: "1h" # <-- duration to wait before rolling out version workloads on credential update
```

Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

We recommend using a “Gardener” managed cluster to deploy CAP applications managed with CAP Operator.

Set up the following prerequisites in the Kubernetes cluster before installing CAP Operator:

Istio (version >= 1.22)

The Istio service mesh is used for HTTP traffic management. CAP Operator creates Istio resources to manage incoming HTTP requests to the application and to route requests on specific (tenant) subdomains.

Determine the public ingress gateway subdomain and the overall shoot domain for the system, and specify them in the chart values. See here for an example.

Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

Prepare the SAP BTP global account and provider subaccount

CAP-based applications use various SAP BTP services created in a provider subaccount. Before deploying the application, create a global account and entitle the required services, then create a provider subaccount where the service instances can be created. See the SAP BTP account administration documentation for details.

Create service instances and bindings

A multi-tenant CAP-based application consumes the following SAP BTP services. Some parameters require special attention during service instance creation. Service keys (bindings) generate access credentials that must be provided as Kubernetes Secrets in the namespace where the application is deployed.

Configuring Additional CA Certificates

Mon, 01 Jan 0001 00:00:00 +0000

When tlsMode is set to Mutual or OptionalMutual on a Domain or ClusterDomain, Istio requires a CA certificate to verify client certificates presented during the TLS handshake. Provide this certificate via certConfig.additionalCACertificate.

The operator stores the certificate as a Kubernetes Secret (key: ca.crt) in the Istio Ingress Gateway namespace, where Istio reads it.

apiVersion: sme.sap.com/v1alpha2
kind: ClusterDomain  # also applies to Domain
metadata:
 name: cap-example-domain
spec:
 domain: myapp.example.com
 ingressSelector:
 app: istio-ingressgateway
 istio: ingressgateway
 tlsMode: Mutual
 certConfig:
 additionalCACertificate: |
 -----BEGIN CERTIFICATE-----
 MIIFZjCCA06gAwIBAgIQGHcPvmUGa79M6pM42bGFYjANBgkqhkiG9w0BAQsFADBN
 ...
 -----END CERTIFICATE-----

Removing certConfig.additionalCACertificate from the spec causes the operator to delete the corresponding secret.

CAP Application Components

Mon, 01 Jan 0001 00:00:00 +0000

A full-stack application built with the SAP Cloud Application Programming Model has the following components:

SAP BTP Service Instances

Multi-tenant CAP-based applications consume services from SAP BTP such as SAP Authorization and Trust Management Service and SAP Software-as-a-Service Provisioning service. You need to create these service instances within an SAP BTP provider account along with service keys (bindings) that generate the credentials used by the application to access these services.

CAP Application Server

The application provides data models that are deployed to the connected database. An HTTP server exposes defined services and handles server-side application logic. For more details, see the SAP Cloud Application Programming Model documentation. It is also possible to split the application into multiple servers (services) that work together.

CAPApplicationVersion

Mon, 01 Jan 0001 00:00:00 +0000

The CAPApplicationVersion has the following high-level structure:

apiVersion: sme.sap.com/v1alpha2
kind: CAPApplicationVersion
metadata:
 name: cav-cap-app-v1
 namespace: cap-ns
spec:
 version: 3.2.1 # <-- semantic version (must be unique within the versions of a CAP application)
 capApplicationInstance: cap-app
 registrySecrets: # <-- image pull secrets to be used in the workloads
 - regcred
 workloads: # <-- define deployments and jobs used for this application version
 - name: "cap-backend"
 deploymentDefinition: # ...
 consumedBTPServices: # ...
 - name: "app-router"
 deploymentDefinition: # ...
 consumedBTPServices: # ...
 - name: "service-content"
 jobDefinition: # ...
 consumedBTPServices: # ...
 - name: "tenant-operation"
 jobDefinition: # ...
 consumedBTPServices: # ...
 tenantOperations: # ... <-- (optional)

A CAPApplicationVersion is always associated with a CAPApplication in the same namespace, referenced via the capApplicationInstance attribute.
The workloads array defines the software components of the application. Examples include a deployment for the CAP application server or a job for tenant operations. Each workload must have either a deploymentDefinition or a jobDefinition. See the next section for details.
The optional tenantOperations attribute defines a sequence of steps (jobs) to execute during tenant operations (provisioning, upgrade, or deprovisioning).

The CAPApplicationVersion resource is immutable — its spec must not be modified after deployment. This is enforced by webhooks, which we recommend keeping active (the default).

Deploying a CAP Application

Mon, 01 Jan 0001 00:00:00 +0000

Deploying a multi-tenant CAP application involves defining several key resources provided by CAP Operator. These resources manage the application’s runtime components and external traffic routing.

Key Resources

CAPApplication (capapplications.sme.sap.com): A namespaced resource that represents the application.
CAPApplicationVersion (capapplicationversions.sme.sap.com): A namespaced resource that specifies the version of the application being deployed. It ensures that all runtime components (Deployments, Services, and Jobs) are created with the specified image version in the same namespace.
Domain resources: These resources determine how external traffic reaches the application and how DNS and TLS settings are applied. You can choose between:
- Domain (domains.sme.sap.com): A namespaced resource for a single application.
- ClusterDomain (clusterdomains.sme.sap.com): A cluster-scoped resource that can be shared across multiple applications.

Helm Values

Mon, 01 Jan 0001 00:00:00 +0000

image:
 # -- Default image tag (can be overwritten on component level)
 tag: ""
 # -- Default image pull policy (can be overwritten on component level)
 pullPolicy: ""
# -- Default image pull secrets (can be overwritten on component level)
imagePullSecrets: []
# -- Default pod security content (can be overwritten on component level)
podSecurityContext: {}
# -- Default node selector (can be overwritten on component level)
nodeSelector: {}
# -- Default affinity settings (can be overwritten on component level)
affinity: {}
# -- Default tolerations (can be overwritten on component level)
tolerations: []
# -- Default priority class (can be overwritten on component level)
priorityClassName: ""
# -- Default topology spread constraints (can be overwritten on component level)
topologySpreadConstraints: []
# -- Additional pod labels for all components
podLabels: {}
# -- Additional pod annotations for all components
podAnnotations: {}
# -- Monitoring configuration for all components
monitoring:
 # -- Optionally enable Prometheus monitoring for all components (disabled by default)
 enabled: false
 # -- Prometheus service monitor selector labels
 serviceMonitorSelectorLabels: {}
 # -- Grafana configuration
 grafana:
 dashboard:
 # -- Labels for selecting ConfigMaps with dashboards in Grafana
 configMapLabels:
 grafana_dashboard: "1"

controller:
 # -- Replicas
 replicas: 1
 image:
 # -- Image repository
 repository: ghcr.io/sap/cap-operator/controller
 # -- Image tag
 tag: ""
 # -- Image pull policy
 pullPolicy: ""
 # -- Image pull secrets
 imagePullSecrets: []
 # -- Additional labels for controller pods
 podLabels: {}
 # -- Additional annotations for controller pods
 podAnnotations: {}
 # -- Pod security content
 podSecurityContext: {}
 # -- Node selector
 nodeSelector: {}
 # -- Affinity settings
 affinity: {}
 # -- Tolerations
 tolerations: []
 # -- Priority class
 priorityClassName: ""
 # -- Topology spread constraints
 topologySpreadConstraints: []
 # -- Security context
 securityContext: {}
 resources:
 limits:
 # -- Memory limit
 memory: 500Mi
 # -- CPU limit
 cpu: 0.2
 requests:
 # -- Memory request
 memory: 50Mi
 # -- CPU request
 cpu: 0.02
 # -- Optionally specify list of additional volumes for the controller pod(s)
 volumes: []
 # -- Optionally specify list of additional volumeMounts for the controller container(s)
 volumeMounts: []
 # -- Override the cert manager type (e.g. "gardener" or "cert-manager.io"); if empty, auto-detected via API capabilities
 certManager: ""
 # -- Override the DNS manager type (e.g. "gardener" or "kubernetes"); if empty, auto-detected via API capabilities
 dnsManager: ""
 # -- The dns target mentioned on the public ingress gateway service used in the cluster
 dnsTarget: ""
 # -- Optionally enable detailed opertational metrics for the controller by setting this to true
 detailedOperationalMetrics: false
 maxConcurrentReconciles:
 # -- The maximum number of concurrent reconciles (e.g. "1") for the cap application
 capApplication: ""
 # -- The maximum number of concurrent reconciles (e.g. "3") for the cap application version
 capApplicationVersion: ""
 # -- The maximum number of concurrent reconciles (e.g. "10") for the cap tenant
 capTenant: ""
 # -- The maximum number of concurrent reconciles (e.g. "10") for the cap tenant operation
 capTenantOperation: ""
 # -- The maximum number of concurrent reconciles (e.g. "1") for the domain
 domain: ""
 # -- The maximum number of concurrent reconciles (e.g. "1") for the cluster domain
 clusterDomain: ""
 versionMonitoring:
 # -- The URL of the Prometheus server from which metrics related to managed application versions can be queried
 prometheusAddress: ""
 # -- The duration (example 2h) after which versions are evaluated for deletion; based on specified workload metrics
 metricsEvaluationInterval: "1h"
 # -- The duration (example 10m) to wait before retrying to acquire Prometheus client and verify connection, after a failed attempt
 promClientAcquireRetryDelay: "1h"
 clientRateLimiting:
 # -- The maximum queries per second from the controller client to the kubernetes API server (e.g. "20")
 qps: ""
 # -- The maximum burst for throttle (e.g. "30")
 burst: ""
 # -- The delay (example 1h) to wait before rolling out version workloads on credential update
 rolloutDelay: ""

subscriptionServer:
 # -- Replicas
 replicas: 1
 image:
 # -- Image repository
 repository: ghcr.io/sap/cap-operator/server
 # -- Image tag
 tag: ""
 # -- Image pull policy
 pullPolicy: ""
 # -- Image pull secrets
 imagePullSecrets: []
 # -- Additional labels for subscription server pods
 podLabels: {}
 # -- Additional annotations for subscription server pods
 podAnnotations: {}
 # -- Pod security content
 podSecurityContext: {}
 # -- Node selector
 nodeSelector: {}
 # -- Affinity settings
 affinity: {}
 # -- Tolerations
 tolerations: []
 # -- Priority class
 priorityClassName: ""
 # -- Topology spread constraints
 topologySpreadConstraints: []
 # -- Security context
 securityContext: {}
 resources:
 limits:
 # -- Memory limit
 memory: 200Mi
 # -- CPU limit
 cpu: 0.1
 requests:
 # -- Memory request
 memory: 20Mi
 # -- CPU request
 cpu: 0.01
 # -- Optionally specify list of additional volumes for the server pod(s)
 volumes: []
 # -- Optionally specify list of additional volumeMounts for the server container(s)
 volumeMounts: []
 # -- Service port
 port: 4000
 # -- The namespace in the cluster where istio system components are installed
 istioSystemNamespace: istio-system
 # -- Labels used to identify the istio ingress-gateway component
 ingressGatewayLabels:
 istio: ingressgateway
 app: istio-ingressgateway
 # -- The dns target mentioned on the public ingress gateway service used in the cluster
 dnsTarget: public-ingress.clusters.cs.services.sap # replace with the actual cluster domain
 # -- The domain under which the cap operator subscription server would be available
 domain: cap-operator.clusters.cs.services.sap # replace with actual cluster domain
 # -- Certificate manager which can be either `Gardener` or `CertManager`
 certificateManager: Gardener
 # -- Certificate configuration
 # @default -- the `additionalCACertificate` part will contain the "SAP Cloud Root CA" certificate by default
 certificateConfig:
 # -- Optionally specify the corresponding certificate configuration
 gardener:
 # -- Issuer name
 issuerName: ""
 # -- Issuer namespace
 issuerNamespace: ""
 # -- Cert Manager configuration
 certManager:
 # -- Issuer group
 issuerGroup: ""
 # -- Issuer kind
 issuerKind: ""
 # -- Issuer name
 issuerName: ""
 # -- Optionally specify the common name (at most 64 characters). Not needed in most scenarios.
 commonName: ""
 # -- Optionally specify additional CA Certificate
 # @default -- this will contain the "SAP Cloud Root CA" certificate by default
 additionalCACertificate: |
 -----BEGIN CERTIFICATE-----
 MIIFZjCCA06gAwIBAgIQGHcPvmUGa79M6pM42bGFYjANBgkqhkiG9w0BAQsFADBN
 MQswCQYDVQQGEwJERTERMA8GA1UEBwwIV2FsbGRvcmYxDzANBgNVBAoMBlNBUCBT
 RTEaMBgGA1UEAwwRU0FQIENsb3VkIFJvb3QgQ0EwHhcNMTkwMjEzMTExOTM2WhcN
 MzkwMjEzMTEyNjMyWjBNMQswCQYDVQQGEwJERTERMA8GA1UEBwwIV2FsbGRvcmYx
 DzANBgNVBAoMBlNBUCBTRTEaMBgGA1UEAwwRU0FQIENsb3VkIFJvb3QgQ0EwggIi
 MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQChbHLXJoe/zFag6fB3IcN3d3HT
 Y14nSkEZIuUzYs7B96GFxQi0T/2s971JFiLfB4KaCG+UcG3dLXf1H/wewq8ahArh
 FTsu4UR71ePUQiYlk/G68EFSy2zWYAJliXJS5k0DFMIWHD1lbSjCF3gPVJSUKf+v
 HmWD5e9vcuiPBlSCaEnSeimYRhg0ITmi3RJ4Wu7H0Xp7tDd5z4HUKuyi9XRinfvG
 kPALiBaX01QRC51cixmo0rhVe7qsNh7WDnLNBZeA0kkxNhLKDl8J6fQHKDdDEzmZ
 KhK5KxL5p5YIZWZ8eEdNRoYRMXR0PxmHvRanzRvSVlXSbfqxaKlORfJJ1ah1bRNt
 o0ngAQchTghsrRuf3Qh/2Kn29IuBy4bjKR9CdNLxGrClvX/q26rUUlz6A3lbXbwJ
 EHSRnendRfEiia+xfZD+NG2oZW0IdTXSqkCbnBnign+uxGH5ECjuLEtvtUx6i9Ae
 xAvK2FqIuud+AchqiZBKzmQAhUjKUoACzNP2Bx2zgJOeB0BqGvf6aldG0n2hYxJF
 8Xssc8TBlwvAqtiubP/UxJJPs+IHqU+zjm7KdP6dM2sbE+J9O3n8DzOP0SDyEmWU
 UCwnmoPOQlq1z6fH9ghcp9bDdbh6adXM8I+SUYUcfvupOzBU7rWHxDCXld/24tpI
 FA7FRzHwKXqMSjwtBQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
 BAUwAwEB/zAdBgNVHQ4EFgQUHLxmKw7KjUufjZNxqQ/KZ0ZpEyIwDQYJKoZIhvcN
 AQELBQADggIBABdSKQsh3EfVoqplSIx6X43y2Pp+kHZLtEsRWMzgO5LhYy2/Fvel
 eRBw/XEiB5iKuEGhxHz/Gqe0gZixw3SsHB1Q464EbGT4tPQ2UiMhiiDho9hVe6tX
 qX1FhrhycAD1xHIxMxQP/buX9s9arFZauZrpw/Jj4tGp7aEj4hypWpO9tzjdBthy
 5vXSviU8L2HyiQpVND/Rp+dNJmVYTiFLuULRY28QbikgFO2xp9s4RNkDBnbDeTrT
 CKWcVsmlZLPJJQZm0n2p8CvoeAsKzIULT9YSbEEBwmeqRlmbUaoT/rUGoobSFcrP
 jrBg66y5hA2w7S3tDH0GjMpRu16b2u0hYQocUDuMlyhrkhsO+Qtqkz1ubwHCJ8PA
 RJw6zYl9VeBtgI5F69AEJdkAgYfvPw5DJipgVuQDSv7ezi6ZcI75939ENGjSyLVy
 4SuP99G7DuItG008T8AYFUHAM2h/yskVyvoZ8+gZx54TC9aY9gPIKyX++4bHv5BC
 qbEdU46N05R+AIBW2KvWozQkjhSQCbzcp6DHXLoZINI6y0WOImzXrvLUSIm4CBaj
 6MTXInIkmitdURnmpxTxLva5Kbng/u20u5ylIQKqpcD8HWX97lLVbmbnPkbpKxo+
 LvHPhNDM3rMsLu06agF4JTbO8ANYtWQTx0PVrZKJu+8fcIaUp7MVBIVZ
 -----END CERTIFICATE-----

webhook:
 # -- Replicas
 replicas: 1
 image:
 # -- Image repository
 repository: ghcr.io/sap/cap-operator/web-hooks
 # -- Image tag
 tag: ""
 # -- Image pull policy
 pullPolicy: ""
 # -- Image pull secrets
 imagePullSecrets: []
 # -- Additional labels for validating webhook pods
 podLabels: {}
 # -- Additional annotations for validating webhook pods
 podAnnotations: {}
 # -- Pod security content
 podSecurityContext: {}
 # -- Node selector
 nodeSelector: {}
 # -- Affinity settings
 affinity: {}
 # -- Tolerations
 tolerations: []
 # -- Priority class
 priorityClassName: ""
 # -- Topology spread constraints
 topologySpreadConstraints: []
 # -- Security context
 securityContext: {}
 resources:
 limits:
 # -- Memory limit
 memory: 200Mi
 # -- CPU limit
 cpu: 0.1
 requests:
 # -- Memory request
 memory: 20Mi
 # -- CPU request
 cpu: 0.01
 # -- Service port
 service:
 # -- Service type
 type: ClusterIP
 # -- Service port
 port: 443
 # -- Target port
 targetPort: 1443
 # -- Optionally specify list of additional volumes for the webhook pod(s)
 volumes: []
 # -- Optionally specify list of additional volumeMounts for the webhook container(s)
 volumeMounts: []
 # -- Certificate manager which can be either `Default` or `CertManager`
 certificateManager: "Default"
 # -- Optionally specify the corresponding certificate configuration
 certificateConfig:
 certManager:
 # -- Issuer group
 issuerGroup: ""
 # -- Issuer kind
 issuerKind: ""
 # -- Issuer name
 issuerName: ""

Subscription Server

Mon, 01 Jan 0001 00:00:00 +0000

The Subscription Server handles HTTP requests from the SAP Software-as-a-Service Provisioning service for tenant subscription operations on SAP Cloud Application Programming Model applications installed in the cluster.

During the creation of a saas-registry service instance (in the provider subaccount), callback URLs are configured to point to the subscription server routes. Additionally, the getDependencies URLs can also be configured to point to the subscription server routes.

When a consumer tenant subscribes to an application managed by the operator, the subscription server receives the callback, validates the request using credentials from the corresponding SubscriptionProvider resource, and creates a Subscription resource in the namespace of the identified CAPApplication. The controller then creates the CAPTenant and drives it through the provisioning flow.

What's New

Mon, 01 Jan 0001 00:00:00 +0000

Recent updates

v1alpha2 API Version

CAP Operator now uses v1alpha2 as the default API version (from release 0.37.0). The new version removes the deprecated globalAccountId and domains fields from CAPApplication. See the CAPApplication resource reference for the updated spec.

Subscription Resource

The new Subscription resource represents an active consumer subscription to a CAP application. It is created and managed by the subscription server in response to SaaS Provisioning service callbacks. Learn more about the Subscription resource.

SubscriptionProvider Resource

The new SubscriptionProvider resource is automatically maintained by the controller to cache subscription credentials and pre-computed dependency information for efficient handling of subscription requests. Learn more about the SubscriptionProvider resource.

SubscriptionProvider

Mon, 01 Jan 0001 00:00:00 +0000

Warning

SubscriptionProvider resources are fully managed by CAP Operator. They are automatically created and kept in sync by the controller whenever a CAPApplication is reconciled. Do not create, modify, or delete them manually.

A SubscriptionProvider is created by the controller in the same namespace as its owning CAPApplication, with the same name. It stores pre-computed subscription credentials and dependency information derived from the CAPApplication spec. The subscription server uses it to:

Subscription

Mon, 01 Jan 0001 00:00:00 +0000

Warning

Subscription resources are fully managed by CAP Operator. They are created and deleted exclusively by the subscription server in response to callbacks from the SAP Software-as-a-Service Provisioning service or SMS. Do not create, modify, or delete them manually.

A Subscription represents an active subscription of a consumer subaccount to a CAP application. When a consumer subscribes via the SAP BTP cockpit or the SaaS Provisioning service API, the subscription server creates a Subscription resource in the namespace of the corresponding CAPApplication. The controller then creates a CAPTenant as a child of the Subscription and drives it through the provisioning flow.

CAPTenant

Mon, 01 Jan 0001 00:00:00 +0000

Warning

The CAPTenant resource is completely managed by CAP Operator and must not be created or modified manually. For details of how CAPTenant is created, see tenant subscription.

The CAPTenant resource indicates the existence of a tenant in the related application (or one that is currently being provisioned). The resource starts with a Provisioning state and moves to Ready when successfully provisioned. Managing tenants as Kubernetes resources allows you to control not only the lifecycle of the entity, but also other requirements that must be fulfilled for the application to serve tenant-specific requests (for example, creating networking resources).

Configuring cert-manager Certificates

Mon, 01 Jan 0001 00:00:00 +0000

When the operator is installed with the cert-manager certificate manager (configured via the CERT_MANAGER environment variable), it creates a cert-manager Certificate resource for each Domain or ClusterDomain. Every Certificate must reference an issuer. By default the operator uses a ClusterIssuer named cluster-ca. Use certConfig.certManager.issuerRef to override this with any issuer available in your cluster.

Default behavior

If certConfig.certManager is not set, the operator uses the following issuer reference:

Field	Default
`name`	`cluster-ca`
`kind`	`ClusterIssuer`
`group`	`cert-manager.io`

Configuring a custom issuer

Set certConfig.certManager.issuerRef on a Domain or ClusterDomain to point to any cert-manager issuer:

Tenant Subscription

Mon, 01 Jan 0001 00:00:00 +0000

In CAP Operator, a valid tenant for an application is represented by the CAPTenant resource. It references the CAPApplication it belongs to and specifies the details of the SAP BTP subaccount that represents the tenant.

apiVersion: sme.sap.com/v1alpha2
kind: CAPTenant
metadata:
 name: cap-app-01-consumer
 namespace: cap-app-01
spec:
 capApplicationInstance: cap-app-01 # <-- reference to the CAPApplication
 subDomain: app-consumer
 tenantId: aa2bae55d7b5-1279-456564-a7b0-aa2bae55d7b5
 version: "1.0.0" # <-- expected version of the application
 versionUpgradeStrategy: always # <-- always / never

Tenant Provisioning

Tenant provisioning begins when a consumer subaccount subscribes to the application, either via the SAP BTP cockpit or using the SaaS Provisioning service APIs. This triggers an asynchronous callback from the SaaS Provisioning service into the cluster, which is handled by the subscription server. The subscription server validates the request using credentials from the SubscriptionProvider resource and creates a Subscription resource in the namespace of the identified CAPApplication. The controller, observing the new Subscription, then creates a CAPTenant instance to represent the consumer tenant.

Application Upgrade

Mon, 01 Jan 0001 00:00:00 +0000

An important lifecycle aspect of operating multi-tenant CAP applications is the tenant upgrade process. With CAP Operator, tenant upgrades can be fully automated by providing a new CAPApplicationVersion custom resource.

As covered in initial deployment, the CAPApplicationVersion resource describes the workloads of an application version, including the container image and services consumed by each component. To upgrade the application, create a new CAPApplicationVersion with updated image values for each component and a higher semantic version in the version field. See API Reference.

CAPTenantOperation

Mon, 01 Jan 0001 00:00:00 +0000

Warning

The CAPTenantOperation resource is managed by CAP Operator and must not be created or modified manually. It is created by the CAPTenant to execute provisioning, deprovisioning, or upgrade operations.

apiVersion: sme.sap.com/v1alpha2
kind: CAPTenantOperation
metadata:
 name: cap-app-consumer-ge455-77kb9
 namespace: cap-ns
spec:
 capApplicationVersionInstance: cav-cap-app-v2
 operation: upgrade
 steps:
 - continueOnFailure: true
 name: tenant-operation
 type: CustomTenantOperation
 - name: tenant-operation
 type: TenantOperation
 - name: create-test-data
 type: CustomTenantOperation
 subDomain: consumer-x
 tenantId: cb46733-1279-48be-fdf434-aa2bae55d7b5

The example above shows a CAPTenantOperation for an upgrade operation. In addition to tenant details, it specifies the CAPApplicationVersion to use. For upgrade and provisioning operations, this is the target version; for deprovisioning, it is the tenant’s current version.

Service Exposure

Mon, 01 Jan 0001 00:00:00 +0000

Exposing Service Workloads

This guide explains how to deploy applications with tenant-agnostic service workloads. These workloads can be part of multi-tenant applications or standalone applications that are entirely tenant-agnostic.

Configuration

Service Exposure Setup

The serviceExposures section in the CAPApplicationVersion configuration is used to expose workloads. Each entry in the serviceExposures array specifies a subdomain under which workloads are accessible, with support for multiple routes per subdomain.

For details on configuring routes, see the Route API reference.

Rollout on Credential Update

Mon, 01 Jan 0001 00:00:00 +0000

When SAP BTP service credentials are rotated — for example, by a credential rotation tool or by re-binding a service instance — the Kubernetes Secrets holding those credentials are updated. By default, running application workloads are not restarted and continue to use the old credentials until the next deployment or a manual rollout.

Enabling rolloutOnCredentialUpdate on a CAPApplication resource instructs CAP Operator to watch the referenced BTP service credential Secrets and automatically trigger a rolling restart of affected Deployments whenever their credentials change.

CAPTenantOutput

Mon, 01 Jan 0001 00:00:00 +0000

CAPTenantOutput can be used to add additional data to the asynchronous callback parameters sent by the SaaS Provisioning service during tenant onboarding. The resource is not reconciled; it is consumed by the subscription server to generate additional callback data. It has the following structure:

apiVersion: sme.sap.com/v1alpha2
kind: CAPTenantOutput
metadata:
 name: cap-app-consumer-output
 namespace: cap-ns
 labels:
 sme.sap.com/btp-tenant-id: cb46733-1279-48be-fdf434-aa2bae55d7b5
spec:
 subscriptionCallbackData: '{foo: bar}'

The example above shows a resource associated with a tenant via the sme.sap.com/btp-tenant-id label, which must be set by consumers.

Domain

Mon, 01 Jan 0001 00:00:00 +0000

A Domain resource is namespace-scoped. All sub-resources — Gateway, DNSEntry, and (with Gardener certificate manager) the Certificate — are created in the same namespace as the Domain.

apiVersion: sme.sap.com/v1alpha2
kind: Domain
metadata:
 namespace: cap-app-01
 name: cap-app-01-primary
spec:
 domain: my.cluster.shoot.url.k8s.example.com
 ingressSelector:
 app: istio-ingressgateway
 istio: ingressgateway
 tlsMode: Simple  # Simple (default), Mutual, or OptionalMutual
 dnsMode: Wildcard  # None (default), Wildcard, Subdomain, or Custom
 dnsTarget: public-ingress.cluster.domain  # Optional
 certConfig: # Optional; only relevant when tlsMode is Mutual or OptionalMutual
 additionalCACertificate: |
 -----BEGIN CERTIFICATE-----
 ...
 -----END CERTIFICATE-----

Fields

domain — the DNS domain name. The TLS certificate is issued for the wildcard *.domain.

Version Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

In a continuous delivery environment where new application versions are deployed frequently, monitoring and cleaning up older unused versions is important for conserving cluster resources (compute, memory, storage) and keeping the system manageable. CAP Operator allows application developers and operations teams to define how an application version is monitored for usage.

Integration with Prometheus

Prometheus is the industry standard for monitoring application metrics and provides a wide variety of tools for managing and reporting metrics. The CAP Operator controller can be connected to a Prometheus server by setting the PROMETHEUS_ADDRESS environment variable (see Configuration). The controller then queries application-related metrics based on the workload specification of CAPApplicationVersion resources. Prometheus is only required to evaluate workloads that declare deletionRules. When PROMETHEUS_ADDRESS is not set, or the configured server is unreachable, the cleanup loop still runs. Versions whose deployment workloads declare no deletionRules can still be cleaned up in that case. Versions that do declare deletionRules are skipped — they are neither deleted nor surfaced as errors — and will be re-evaluated on the next cycle once Prometheus becomes available again.

ClusterDomain

Mon, 01 Jan 0001 00:00:00 +0000

A ClusterDomain resource is cluster-scoped and intended for domains shared across multiple applications or namespaces. All sub-resources — Gateway, DNSEntry, and (with Gardener certificate manager) the Certificate — are created in the namespace where CAP Operator is installed.

apiVersion: sme.sap.com/v1alpha2
kind: ClusterDomain
metadata:
 name: common-external-domain
spec:
 domain: my.example.com
 ingressSelector:
 app: istio-ingressgateway
 istio: ingressgateway
 tlsMode: Simple  # Simple (default), Mutual, or OptionalMutual
 dnsMode: Subdomain  # None (default), Wildcard, Subdomain, or Custom
 dnsTarget: public-ingress.cluster.domain  # Optional
 certConfig: # Optional; only relevant when tlsMode is Mutual or OptionalMutual
 additionalCACertificate: |
 -----BEGIN CERTIFICATE-----
 ...
 -----END CERTIFICATE-----

Fields

domain — the DNS domain name. The TLS certificate is issued for the wildcard *.domain.

Operator Metrics

Mon, 01 Jan 0001 00:00:00 +0000

Overview

CAP Operator includes built-in Prometheus metrics that enable you to effectively monitor and analyze the operator’s performance. These metrics provide insights into resource usage, potential issues, and overall operator health. The metrics are accessible at the /metrics endpoint on port 9090 of both the Controller and the Subscription Server.

Controller Metrics

The Controller emits several types of metrics, including:

Standard Go Metrics: These metrics are provided by the Prometheus Go client and include runtime statistics.
Workqueue Metrics: These metrics are relevant to the resources being reconciled and are based on the MetricsProvider.
Specific metrics: mentioned below.

Specific Metrics

Reconcile Errors – cap_op_reconcile_errors, e.g.:

cap_op_reconcile_errors{kind="CAPApplication",name="my-app",namespace="app"} 11

Type: Counter
Description: This metric tracks the total number of resources that failed to reconcile for each resource kind, such as CAPApplication.

Tenant Operations – cap_op_tenant_operations, e.g.

cap_op_tenant_operations{app="<hash>",operation="provisioning"} 83

Type: Counter
Description: This metric provides insights into overall tenant operations being performed.

Detailed Operational Metrics

To gain deeper insights, you can enable more granular metrics by setting the environment variable DETAILED_OPERATIONAL_METRICS to "true".

Security

Mon, 01 Jan 0001 00:00:00 +0000

Securing Applications

We strongly recommend that applications implement the necessary authentication and authorization mechanisms to safeguard exposed workloads. This includes implicitly exposed tenant workloads and explicitly exposed service workloads.

When using SAP Authorization and Trust Management Service in the application, this can be done as explained in this guide.

Istio

You may also consider using Istio’s security features, for instance using specific workload selectors to secure exposed workloads.

CAP Operator

CAPApplication

Controller

Custom DNS Templates

Configuration

Optional Configuration

Enable Service Monitors for metrics

Set up Prometheus integration for Version Monitoring

Configure maximum concurrent reconciles

Configure controller client rate limiting

Configure controller rollout delay

Prerequisites

Istio (version >= 1.22)

Prerequisites

Prepare the SAP BTP global account and provider subaccount

Create service instances and bindings

Configuring Additional CA Certificates

CAP Application Components

SAP BTP Service Instances

CAP Application Server

CAPApplicationVersion

Deploying a CAP Application

Key Resources

Helm Values

Subscription Server

What's New

Recent updates

SubscriptionProvider

Subscription

CAPTenant

Configuring cert-manager Certificates

Default behavior

Configuring a custom issuer

Tenant Subscription

Tenant Provisioning

Application Upgrade

CAPTenantOperation

Service Exposure

Exposing Service Workloads

Configuration

Service Exposure Setup

Rollout on Credential Update

CAPTenantOutput

Domain

Fields

Version Monitoring

Integration with Prometheus

ClusterDomain

Fields

Operator Metrics

Overview

Controller Metrics

Specific Metrics

Detailed Operational Metrics

Security

Securing Applications

Istio