SAP Business Technology Platform (SAP BTP) Service Operator for Kubernetes

With the SAP BTP service operator, you can consume SAP BTP services from your Kubernetes cluster using Kubernetes-native tools. SAP BTP service operator allows you to provision and manage service instances and service bindings of SAP BTP services so that your Kubernetes-native applications can access and use needed services from the cluster.
The SAP BTP service operator is based on the Kubernetes Operator pattern.

Table of Contents

• Overview and Architecture
• Prerequisites for Deployment
• Installation and Setup
• Managing Access Permissions
• Configuring Multiple Subaccounts
• Using the SAP BTP Service Operator
• Creating Service Instances
• Managing Service Bindings
• Service Binding Secret Formats
• Automating Service Binding Rotation
• Specifying Parameters
• Reference Documentation
• Service Instance Properties
• Service Binding Properties
• Uninstalling the SAP BTP Service Operator
• License
• Troubleshooting and Support

Overview and Architecture

The SAP BTP Service Operator enables seamless integration with SAP Business Technology Platform (BTP) services by communicating with the SAP Service Manager via the Open Service Broker API. It acts as an intermediary, allowing the Kubernetes API Server to provision services and retrieve credentials for applications. The operator leverages a Custom Resource Definitions (CRDs)-based architecture for extensibility and modularity.

Back to top

Prerequisites for Deployment

Before installing the SAP BTP Service Operator, ensure the following requirements are met:

• SAP BTP Global Account and Subaccount
• Familiarity with SAP Service Manager.
• A Kubernetes cluster running version 1.17 or higher.
• kubectl version 1.17 or higher.
• Helm version 3.0 or higher.

Back to top

Installation and Setup

To deploy the SAP BTP Service Operator, follow these steps:

• Install cert-manager:
• For operator releases v0.1.18 or higher, use cert-manager v1.6.0 or later.

• For releases v0.1.17 or lower, use cert-manager versions below v1.6.0.

• Obtain access credentials:

• Create an instance of the SAP Service Manager service (technical name: service-manager) with the service-operator-access plan.
• Note: If the plan is not visible, entitle your subaccount for the SAP Service Manager service. See Configure Entitlements and Quotas for Subaccounts.

• Create a service binding to retrieve credentials. For details, see:

  • Creating Service Instances Using the SAP BTP Cockpit
  • Creating Service Instances Using BTP CLI
  • Creating Service Bindings Using the SAP BTP Cockpit
  • Creating Service Bindings Using BTP CLI.

• Retrieve the credentials from the binding. Example default binding:

{
    "clientid": "<clientid>",
    "clientsecret": "<clientsecret>",
    "url": "https://mysubaccount.authentication.eu10.hana.ondemand.com",
    "xsappname": "b15166|service-manager!b1234",
    "sm_url": "https://service-manager.cfapps.eu10.hana.ondemand.com"
}

Example binding with X.509 certificate:

{
    "clientid": "<clientid>",
    "certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----..-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n",
    "key": "-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----\n",
    "certurl": "https://mysubaccount.authentication.cert.eu10.hana.ondemand.com",
    "xsappname": "b15166|service-manager!b1234",
    "sm_url": "https://service-manager.cfapps.eu10.hana.ondemand.com"
}

Note: The service-operator-access credentials are intended exclusively for technical communication between the BTP Service Operator and Service Manager. They are not designed for direct API access. If you need to call Service Manager APIs directly, create a separate Service Manager instance with the subaccount-admin plan and use those credentials instead.

• Add the SAP BTP Service Operator Helm chart repository:

helm repo add sap-btp-operator https://sap.github.io/sap-btp-service-operator

• Deploy the operator using the obtained access credentials:

Note: If you are deploying the SAP BTP service operator in the registered cluster based on the Service Catalog (svcat) and Service Manager agent so that you can migrate svcat-based content to service operator-based content, add --set cluster.id=<clusterID> to your deployment script. For more information, see the step 2 of the Setup section of Migration to SAP BTP service operator.

An example of the deployment that uses the default access credentials type:

helm upgrade --install sap-btp-operator sap-btp-operator/sap-btp-operator \
    --create-namespace \
    --namespace=sap-btp-operator \
    --set manager.secret.clientid=<clientid> \
    --set manager.secret.clientsecret=<clientsecret> \
    --set manager.secret.sm_url=<sm_url> \
    --set manager.secret.tokenurl=<auth_url>

An example of the deployment that uses the X.509 certificate:

helm upgrade --install sap-btp-operator sap-btp-operator/sap-btp-service-operator \
    --create-namespace \
    --namespace=sap-btp-operator \
    --set manager.secret.clientid=<clientid> \
    --set manager.secret.tls.crt="$(cat /path/to/cert)" \
    --set manager.secret.tls.key="$(cat /path/to/key)" \
    --set manager.secret.sm_url=<sm_url> \
    --set manager.secret.tokenurl=<auth_url>

The credentials provided during the installation are stored in a secret named sap-btp-service-operator, in the sap-btp-operator namespace. These credentials are used by the BTP service operator to communicate with the SAP BTP subaccount.

BTP Access Secret Structure

Default Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: sap-btp-service-operator
  namespace: sap-btp-operator
type: Opaque
stringData:
  clientid: "<clientid>"
  clientsecret: "<clientsecret>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

mTLS Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: sap-btp-service-operator
  namespace: sap-btp-operator
type: Opaque
stringData:
  clientid: "<clientid>"
  tls.crt: "<certificate>"
  tls.key: "<key>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

Note: To rotate the credentials between the BTP service operator and Service Manager, you have to create a new binding for the service-operator-access service instance, and then execute the setup script again with the new set of credentials. Afterward, you can delete the old binding.

Back to top

Using Custom Certificate Authorities

The SAP BTP Service Operator can be configured to trust custom CA certificates in addition to the standard system CA bundle. This enables the operator to establish secure HTTPS connections with SAP BTP using certificates from your own trusted sources.

This is particularly useful in restricted or disconnected environments where public CAs may be unavailable.

Configuration

Custom CA certificates are configured through the Helm chart. You configure custom CAs using the customCACerts array under manager in values.yaml. Each entry must be a base64-encoded PEM certificate.

    --set 'manager.customCACerts[0]'='LS0tLS1CRUdJTi...'  # Base64-encoded PEM certificate

Managing Access Permissions

By default, the SAP BTP operator has cluster-wide permissions. You can also limit them to one or more namespaces; for this, you need to set the following two Helm parameters:

--set manager.allow_cluster_access=false
--set manager.allowed_namespaces={namespace1,namespace2}

Note: If allow_cluster_access is set to true, then the allowed_namespaces parameter is ignored.

Back to top

Configuring Multiple Subaccounts

By default, a Kubernetes cluster is associated with a single subaccount (as described in step 4 of the Installation and Setup section). Consequently, any service instance created within any namespace will be provisioned in that subaccount.

However, the SAP BTP service operator also supports multi-subaccount configurations in a single cluster. This is achieved through:

• Namespace-based mapping: Connect different namespaces to separate subaccounts. This approach leverages dedicated credentials configured for each namespace.
• Explicit instance-level mapping: Define the specific subaccount for each service instance, regardless of the namespace context.

Both can be achieved through dedicated secrets managed in the centrally managed namespace. Choosing the most suitable approach depends on your specific needs and application architecture.

Note: The system’s centrally managed namespace is set by the value in .Values.manager.management_namespace. You can provide this value during installation (refer to step 4 in the Installation and Setup section). If you don’t specify this value, the system will use the installation namespace as the default.

Subaccount for a Namespace

To associate a namespace to a specific subaccount, maintain the access credentials to the subaccount in a Secret that is dedicated to a specific namespace. Define a secret named <namespace-name>-sap-btp-service-operator in the centrally-managed namespace.

Default Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: <namespace-name>-sap-btp-service-operator
  namespace: <centrally-managed-namespace>
type: Opaque
stringData:
  clientid: "<clientid>"
  clientsecret: "<clientsecret>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

mTLS Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: "<namespace-name>-sap-btp-service-operator"
  namespace: "<centrally-managed-namespace>"
type: Opaque
stringData:
  clientid: "<clientid>"
  tls.crt: "<certificate>"
  tls.key: "<key>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

Subaccount for a ServiceInstance Resource

You can deploy service instances belonging to different subaccounts within the same namespace. To achieve this, follow these steps:

• Store access credentials: Securely store the access credentials for each subaccount in separate Secret resources within the centrally-managed namespace.
• Specify subaccount per service: In the ServiceInstance resource, use the btpAccessCredentialsSecret property to reference the specific Secret containing the relevant subaccount’s credentials. This explicitly tells the operator which subaccount to use to provision the service instance.

Define a new secret

Default Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: "<my-secret>"
  namespace: <centrally-managed-namespace>
type: Opaque
stringData:
  clientid: "<clientid>"
  clientsecret: "<clientsecret>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

mTLS Access Credentials

apiVersion: v1
kind: Secret
metadata:
  name: "<my-secret>"
  namespace: <centrally-managed-namespace>
type: Opaque
stringData:
  clientid: "<clientid>"
  tls.crt: "<certificate>"
  tls.key: "<key>"
  sm_url: "<sm_url>"
  tokenurl: "<auth_url>"
  tokenurlsuffix: "/oauth/token"

Configure the secret name in the `ServiceInstance