[BUG] CF provider - ServiceCredentialBinding creates service keys with an unexpected random suffix

[antopraveen]

Summary

When creating an XSUAA ServiceCredentialBinding using the Crossplane Cloud Foundry Provider, the resulting service key in Cloud Foundry is created with an unexpected random suffix appended to the configured name.

For example, if the requested name is:

auditlog-xsuaa-service-key-k8s
the actual service key created in Cloud Foundry is:

auditlog-xsuaa-service-key-k8s-dvo6q
The expected behavior is that the service key name should exactly match the name specified in the ServiceCredentialBinding resource.

Expected Behavior

Given the following resource:

spec:
  forProvider:
    name: auditlog-xsuaa-service-key-k8s

the Cloud Foundry service key should be created as:

auditlog-xsuaa-service-key-k8s
without any additional suffix.

Actual Behavior

The Cloud Foundry provider successfully creates the binding, but the service key appears in Cloud Foundry as:

auditlog-xsuaa-service-key-k8s-dvo6q
where a random suffix is appended to the requested name.

The Crossplane resource reaches the Ready=True state, but the generated service key name does not match the configured name.

Steps to Reproduce

Create an XSUAA Service Instance.
Create the following ServiceCredentialBinding:

apiVersion: cloudfoundry.crossplane.io/v1alpha1
kind: ServiceCredentialBinding
spec:
  forProvider:
    name: auditlog-xsuaa-service-key-k8s
    type: key
    serviceInstanceRef:
      name: xsuaa-k8s-aws-cf-del101

Verify the created service key in the Cloud Foundry Cockpit.
Observed Result

Service key name:

auditlog-xsuaa-service-key-k8s-dvo6q
Expected Result

Service key name:

auditlog-xsuaa-service-key-k8s

Additional Observations

Creating the same service key manually through the Cloud Foundry Cockpit preserves the configured name and does not append a random suffix.
This suggests the suffix is introduced by the API flow used by the provider rather than being inherent XSUAA behavior.
The provider should use the supplied name as the service key name instead of allowing an auto-generated suffix.

Environment
Crossplane Cloud Foundry Provider: openmcp.common.repositories.cloud.sap/mirror/provider-cloudfoundry:v0.3.3

Question

Is the provider intentionally using an API that generates unique names for service keys, or is this an implementation issue? Since both the Cloud Foundry Cockpit and cf create-service-key preserve the requested name, it would be expected that the provider behaves consistently by creating the service key with the exact configured name.

This would help us in refering service creds at places where secrets are not refered.

[antopraveen]

It may be worth considering a design where the configured service credential name (e.g., auditlog-xsuaa-service-key-k8s) always represents the active credential, while rotated/expiring credentials are created with versioned or suffixed names (e.g., auditlog-xsuaa-service-key-k8s-). This would provide a stable, predictable identifier for consumers while still supporting seamless credential rotation.

Alternatively, would it be possible to expose the active service credentials name in the status field so that we can reference it?

[mpechkurov]

@lennardrother could you investigate if this is possible.
Thank you.

[lennardrother]

Hi @antopraveen,

the suffix is required because Cloud Foundry service keys cannot be renamed. During rotation, the provider creates the new key before deleting the old one. Without a suffix this would cause a name collision because the name of service keys must be unique per service instance. We apply the suffix regardless of whether rotation is enabled, so that enabling rotation later doesn't cause a name collision.

Exposing the active key name in the status would be possible. The GUID is already there. Let me check with my colleagues regarding this request.

[lennardrother]

Hi @antopraveen, there are no objections against exposing the active key name in the status. Would this solution work for you?

[antopraveen]

Hi @lennardrother yes it's fine for me.

[lennardrother]

Hi @antopraveen, I created a release candidate that has this feature implemented: https://github.com/sap/crossplane-provider-cloudfoundry/pkgs/container/crossplane-provider-cloudfoundry%2Fcrossplane%2Fprovider-cloudfoundry/1031979920?tag=v0.0.0-06fda6a9dc20d6b74ab1804685f5c5e1bbdf4d93

It would be great if you could try it out in a separate test crossplane of yours and provide feedback. Feel free to reach out if you need help with the installation! 😊