[bug] OpenStackCluster's identityRef requires secrets in the same namespace, breaking cross-namespace credential usage

[wkonitzer]

The identityRef field in OpenStackCluster requires the referenced secret (openstack-cloud-config) to reside in the same namespace as the OpenStackCluster resource. This limitation prevents centralized credential management and complicates the usage of shared credentials across multiple namespaces.

This behavior contrasts with other cloud providers using the ClusterIdentity CR, which supports better abstraction and flexibility for managing credentials.

To Reproduce:

• Create an OpenStackCluster resource in a namespace.
• Attempt to reference a secret in a different namespace using the identityRef field.
• Observe that the operation fails due to the namespace-scoping restriction.

Expected behavior:
The identityRef field should support cross-namespace references to secrets, allowing centralized credential management while maintaining secure access control. Alternatively, an abstraction (e.g., OpenStackClusterIdentity) should handle this seamlessly.

Additional info:

• The CAPO team has expressed hesitation in supporting cross-namespace references due to security concerns.
• The current workaround involves copying the secret into the target namespace, but this exposes the secret to users with access to that namespace.
• This behavior is inconsistent with other cloud providers under Cluster API (CAPI) that use ClusterIdentity CRs for credential abstraction, for example AWS.
• k0rdent documentation states: "The Credential object acts like a reference to the underlying credentials. It is namespace-scoped, which means that it must be in the same Namespace with the ClusterDeployment it is referenced in. Actual credentials can be located in any namespace." However, this flexibility is not currently supported in CAPO.

Proposed solutions include:

• Enhancing CAPO with an OpenStackClusterIdentity abstraction similar to ClusterIdentity.
• Revisiting the Credential system to account for provider-specific quirks without introducing provider-specific code.
• Proposing an update to the CAPI spec to standardize behavior across providers.

Impact:

• Limits credential centralization in multi-namespace environments.
• Increases administrative overhead for managing secrets across namespaces.
• Creates inconsistencies in user experience across providers under CAPI.

[wkonitzer]

kubernetes-sigs/cluster-api-provider-openstack#2386 (comment)

[wkonitzer]

Other options up for discussion

• We state in the docs that we have limitation for OpenStack and Platform Engineer should create secrets for all namespaces manually
• Or we implicitly copy OpenStack credentials secret to all namespaces
• Potentially, we could provide a way to automate using Sveltos, but that should perhaps be opt-in