Kyma

Appearance

Create Service Instances and Service Bindings ​

To use an SAP BTP service in your Kyma cluster, create its service instance and service binding using Kyma dashboard or kubectl.

Prerequisites ​

  • You have the SAP BTP Operator module in your cluster. See Adding and Deleting a Kyma Module.

  • For CLI interactions: kubectl configured to communicate with your Kyma instance. See Access a Kyma Instance Using kubectl.

  • For an enterprise account, you have added quotas to the services you purchased in your subaccount. Otherwise, only default free-of-charge services are listed in the service marketplace. Quotas are automatically assigned to the resources available in trial accounts. For more information, see Configure Entitlements and Quotas for Subaccounts.

  • You know the service offering name and service plan name for the SAP BTP service you want to connect to your Kyma cluster.

    TIP

    To find the service and service plan names, in the SAP BTP cockpit, go to Services->Service Marketplace. Click on the service tile and find its name and Plan.

Create a Service Instance ​

To create a service instance, use either Kyma dashboard or kubectl.

Create a Service Binding ​

With a ServiceBinding custom resource (CR), your application can get access credentials for communicating with an SAP BTP service. These access credentials are available to applications through a Secret resource generated in your cluster.

To create a service binding, use either Kyma dashboard or kubectl.

You can use a given service in your Kyma cluster.

Create a Service Binding for a Service Instance in a Different Namespace ​

  1. To create a service binding for a service instance in a different namespace, set the serviceInstanceNamespace field in the ServiceBinding spec to the namespace where the service instance resides. Replace the placeholders and run:

    yaml
    kubectl create -f - <<EOF
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: {BINDING_NAME}
  namespace: {BINDING_NAMESPACE}
spec:
  serviceInstanceName: {SERVICE_INSTANCE_NAME}
  serviceInstanceNamespace: {INSTANCE_NAMESPACE}
  secretName: {SECRET_NAME}
EOF

  2. To check your service binding status, run:

    bash
    kubectl get servicebindings.services.cloud.sap.com {BINDING_NAME} -n {BINDING_NAMESPACE}

    You see the status Created.

The application in the binding's namespace can use the Secret referenced in the spec.secretName field to access the service instance provisioned in the namespace specified in the spec.serviceInstanceNamespace field.

Restrict Cross-Namespace Bindings ​

To restrict which namespaces can create cross-namespace bindings, add one of the following annotations to the service instance:

  • services.cloud.sap.com/allowCrossNamespaceBinding: "false" - to block cross-namespace bindings from all other namespaces
  • services.cloud.sap.com/allowedNamespacesForBinding - to limit cross-namespace bindings to specific namespaces, add the annotation with a comma-separated list of allowed namespaces (with no spaces), for example: services.cloud.sap.com/allowedNamespacesForBinding: "ns1,ns2".

Without these annotations, any namespace can create cross-namespace bindings for this instance.

If the binding's namespace is not permitted by the service instance's annotations, the Succeeded condition of the binding is set to false with reason Blocked. The binding automatically retries when the service instance's annotations change.

When a cross-namespace binding is blocked, the binding status shows a message indicating that the service instance couldn't be found or doesn't allow cross-namespace binding. You see the same message when the instance doesn't exist. If you see it and you're sure the instance name and namespace are correct, check whether the service instance has cross-namespace binding restrictions set.

To resolve a blocked binding, either remove the restriction from the service instance or update the services.cloud.sap.com/allowedNamespacesForBinding annotation to include the binding's namespace.