"How to create a service key and extract credentials How to inject credentials into Cloud Foundry as a User-Provided Service How to inject credentials into Kyma as a Kubernetes Secret How to rotate and clean up manually shared credentials"

"What do I need before I start?"

" In Choose a Service Sharing Method, you chose manual credential sharing. You have the Subaccount Administrator role collection in the source subaccount. You have installed and configured the btp CLI; see Download and Start Using the btp CLI Client. For Cloud Foundry: You have installed the cf CLI and have the Space Developer role in the target space; see Download and Install the Cloud Foundry CLI. For Kyma: You have configured kubectl for the target cluster and have permissions to create Secrets in the target namespace; see Access a Kyma Instance Using kubectl. For Kyma: You have installed jq for JSON processing in verification steps. "

Share Service Credentials Manually

Overview

You will learn

✔How to create a service key and extract credentials
✔How to inject credentials into Cloud Foundry as a User-Provided Service
✔How to inject credentials into Kyma as a Kubernetes Secret
✔How to rotate and clean up manually shared credentials

N Nina Hingerl November 3, 2026

Created on November 3, 2026

Contributors

More from Nina Hingerl

TUTORIAL Create and Share a Source Service Instance ⏱ 15 min. TUTORIAL Consume a Shared Service Instance in Kyma ⏱ 30 min. TUTORIAL Consume a Shared Service Instance in Cloud Foundry ⏱ 20 min. TUTORIAL Choose a Service Sharing Method ⏱ 15 min.

See all 5 tutorials by Nina Hingerl →

Prerequisites

In Choose a Service Sharing Method, you chose manual credential sharing.
You have the Subaccount Administrator role collection in the source subaccount.
You have installed and configured the btp CLI; see Download and Start Using the btp CLI Client.
For Cloud Foundry: You have installed the cf CLI and have the Space Developer role in the target space; see Download and Install the Cloud Foundry CLI.
For Kyma: You have configured kubectl for the target cluster and have permissions to create Secrets in the target namespace; see Access a Kyma Instance Using kubectl.
For Kyma: You have installed jq for JSON processing in verification steps.

Steps

Intro

Step 1 Understand when to use manual credential sharing

—

Use manual credential sharing when platform-native instance sharing doesn’t cover your scenario. The following table lists common examples:

Scenario	Reason for manual sharing	Approach
Cloud Foundry space in a different subaccount	CF doesn’t support cross-subaccount reference instances	User-Provided Service
Cloud Foundry space in a different region	Reference instances are scoped to a single subaccount	User-Provided Service
Kyma namespace in a different region or global account	`btpAccessCredentialsSecret` requires SAP Service Manager connectivity within the same global account	Kubernetes Secret
External target (external application, on-premise system)	No platform runtime available	Direct credential injection

Important: With manual credential sharing, you bypass the platform’s lifecycle management. You are responsible for credential rotation, transport security, and cleanup.

Step 2 Create a service key on the source instance

A service key generates a set of credentials for the source instance without binding it to a specific application.

To create a service key, run:

Shell

btp create services/binding --subaccount <SOURCE_SUBACCOUNT_ID> --instance-name <INSTANCE_NAME> --name <KEY_NAME> --binding-type key

To retrieve the credentials, run:

Shell

btp get services/binding --subaccount <SOURCE_SUBACCOUNT_ID> --name <KEY_NAME>

Copy the credentials JSON from the output; you need it in the next steps.

Tip: Name service keys to indicate their target location (for example, cls-key-for-eu20-prod-space if you’re sharing an SAP Cloud Logging instance). This naming convention helps you track which key is used where and simplifies rotation.

Step 3 Inject credentials into the target runtime

Choose the injection method that matches your target runtime:

To make the shared credentials available in a Cloud Foundry space, create a User-Provided Service Instance (UPSI).

To create the UPSI, run the following command. Replace <CREDENTIALS_JSON> with the JSON block you copied earlier.
Shell
```
cf cups <UPS_NAME> -p '<CREDENTIALS_JSON>'
```
The -p flag accepts inline JSON. If the JSON is complex, run cf cups <UPS_NAME> -p without a value. The CLI prompts you for each key-value pair.

To bind your application to the UPSI, run:

Shell

cf bind-service <APP_NAME> <UPS_NAME>
cf restage <APP_NAME>

To verify the binding, run:
Shell
```
cf env <APP_NAME>
```
The VCAP_SERVICES section contains the credentials under the User-Provided Service entry.

To make the shared credentials available in a Kyma namespace, create a Kubernetes Secret.

Create a file named manual-credentials-secret.yaml with the following content. Replace the placeholder values with the actual credential values you copied earlier.
YAML
```
apiVersion: v1
kind: Secret
metadata:
  name: <SECRET_NAME>
  namespace: <TARGET_NAMESPACE>
stringData:
  clientid: "<CLIENT_ID>"
  clientsecret: "<CLIENT_SECRET>"
  url: "<SERVICE_URL>"
  # Add other fields from the service key as needed
```
Tip: Map each top-level field from the service key JSON to a separate key in stringData. This approach lets your application reference individual credential fields as environment variables or volume mounts, rather than parsing a single JSON blob.

To create the Secret, run:

Shell

kubectl apply -f manual-credentials-secret.yaml

To verify that the Secret exists and inspect its keys (without exposing values), run:
Shell
```
kubectl get secret <SECRET_NAME> -n <TARGET_NAMESPACE> -o jsonpath='{.data}' | jq 'keys'
```

Your application can now mount this Secret as a volume or reference it in environment variable definitions.

For external targets (external applications, on-premise systems, or third-party platforms), inject the credentials using whatever mechanism the target system supports: environment variables, configuration files, vault integration, or direct API configuration. The service key JSON structure is the same regardless of the target.

Step 4 Rotate credentials

Because the platform doesn’t manage manually shared credentials, you must rotate them according to your organization’s security policy. For service-specific rotation recommendations, see Security Recommendations.

Create a new service key on the source instance:

Shell

btp create services/binding --subaccount <SOURCE_SUBACCOUNT_ID> --instance-name <INSTANCE_NAME> --name <NEW_KEY_NAME> --binding-type key

Retrieve the new credentials:

Shell

btp get services/binding --subaccount <SOURCE_SUBACCOUNT_ID> --name <NEW_KEY_NAME>

Update the target:
- For Cloud Foundry: Update the User-Provided Service with the new credentials.
  Shell
  cf uups <UPS_NAME> -p '<NEW_CREDENTIALS_JSON>' cf restage <APP_NAME>
- For Kyma: Update the Kubernetes Secret. The following command generates the Secret manifest locally without sending it to the cluster (--dry-run=client), then pipes it to kubectl apply to update the existing Secret in place.
  Shell
  # Update the Secret in place (generates YAML locally, then applies it) kubectl create secret generic <SECRET_NAME> \ --namespace <TARGET_NAMESPACE> \ --from-literal=clientid="<NEW_CLIENT_ID>" \ --from-literal=clientsecret="<NEW_CLIENT_SECRET>" \ --from-literal=url="<NEW_SERVICE_URL>" \ --dry-run=client -o yaml | kubectl apply -f -
  Tip: If your application reads credentials at startup (not dynamically), restart the application pods after updating the Secret: kubectl rollout restart deployment/<DEPLOYMENT_NAME> -n <TARGET_NAMESPACE>. Alternatively, Kyma consumers can configure automatic credential rotation using the SAP BTP Operator’s credentialsRotationPolicy. For details, see Rotating Service Bindings.

Delete the old service key:

Shell

btp delete services/binding --subaccount <SOURCE_SUBACCOUNT_ID> --name <OLD_KEY_NAME> --confirm

Step 5 Understand lifecycle behavior

The following table summarizes what happens when you modify manually shared resources.

Action	Effect
Delete the UPSI (`cf delete-service <UPS_NAME>`) or Secret (`kubectl delete secret <SECRET_NAME>`)	Only the local credential copy is removed. The source instance and service key aren’t affected.
Delete the service key (`btp delete services/binding`)	The credentials become invalid. Applications using the UPSI or Secret fail at the next authentication attempt.
Delete the source instance	The credentials become invalid. Applications fail.
Rotate the service key without updating the UPSI or Secret	Applications continue to use the old credentials until you delete the old key.

Important: Use one service key per target location. This limits the blast radius if a key is compromised and simplifies rotation. You can rotate one target at a time without affecting others.

You have successfully shared service credentials manually. For an overview of all sharing methods, see Choose a Service Sharing Method.

Step 6 Test yourself

Resources

Next Steps

Discussion

Share feedback on this tutorial or join the conversation in SAP Community.

Submit detailed feedback

Discuss in Community

Share Service Credentials Manually

Overview

You will learn

More from Nina Hingerl

Prerequisites

Steps

Intro

Resources

Next Steps

Related Tutorials

Discussion

Joule

AI Notice