Skip to content

Cloud Provider Credentials Management in CAPI#

Cloud provider credentials in Cluster API (CAPI) environments are managed through objects in the management cluster. Credential, ClusterIdentity, and Secret (related to ClusterIdentity) objects handle credential storage and management, while a dedicated ConfigMap object is used as a template to render configuration into child clusters.

Configuration Patterns#

The configuration follows two patterns:

ClusterIdentity Pattern

  • Uses a ClusterIdentity resource that defines provider identity configuration
  • References a Secret with credentials
  • Used by Azure and vSphere in-tree providers

Source Secret Pattern

  • Uses only a Secret without ClusterIdentity
  • Secret contains all cloud configuration data
  • Used by OpenStack in-tree provider

In both cases ConfigMap with template code is used to render configuration into child clusters.

Credential Resource#

The Credential resource provides an abstraction layer by either:

  • Referencing a ClusterIdentity through identityRef (ClusterIdentity Pattern).
  • Directly referencing a Secret (Source Secret Pattern).

Credential Secret#

If the ClusterIdentity Patten is being used, the name of the Secret containing the credentials must be .spec.identityRef.name from the Credential object + -secret string suffix.

Template ConfigMap#

  • Marked with projectsveltos.io/template: "true" annotation
  • Contains Go template code for generating child cluster resources via the Sveltos templating system
  • Template processing accesses cluster objects through:
  • Built-in Sveltos variables (Cluster, InfrastructureProvider)
  • getResource function for additionally exposed objects (InfrastructureProviderIdentity, InfrastructureProviderIdentitySecret)
  • It must be created in same Namespace as the ClusterIdentity object it references.

Naming the Template ConfigMap#

The ConfigMap name needs to be .spec.identityRef.name from Credential object + -resource-template string suffix.

Templating System#

The templating system leverages:

Examples#

Provider-specific examples are available in *.credentials.yaml files here.

Let's take Azure provider as an example azure-credentials.yaml

Note

These examples assume the ConfigMap is included in a template. To use these examples directly via kubectl, please replace $$ (double dollar signs) with $ (single dollar sign)

Provider Registration#

Providers are registered through ProviderInterface CR, each provider Helm chart ships with corresponding ProviderInterface object.

Modifications to the Management Spec are needed to enable newly added provider.

For detailed information, refer to Extended Management Configuration.

Every ProviderInterface must carry the standard Cluster API provider label cluster.x-k8s.io/provider: <role>-<name> (for example, infrastructure-aws) so k0rdent can discover it. See ProviderInterface Required Labels for details.

Configuration Examples#

As mentioned previously provider configuration examples can be found here, look for ProviderInterface object inside CAPI Helm charts.

Let's take the Azure provider as an example interface.yaml, as seen, the CR definitions are straightforward.