Providers, ProviderConfig & credentials

How Crossplane authenticates to clouds.

Intermediate12 min · lesson 7 of 12

A provider needs credentials to talk to a cloud, and a ProviderConfig is where you tell it how to authenticate. It references a source of credentials — a Kubernetes Secret, or better, a workload identity (IRSA on EKS, Workload Identity on GKE) so no long-lived key is stored at all. Managed resources then point at a ProviderConfig by name, which lets you run multiple accounts or roles from one control plane.

providerconfig.yaml

apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata: { name: default }
spec:
  credentials:
    source: IRSA        # assume an IAM role via the pod’s service account — no stored key
# or, less ideal, from a Secret:
#   source: Secret
#   secretRef: { namespace: crossplane-system, name: aws-creds, key: creds }

Multiple configs, least privilege

You can define several ProviderConfigs — one per account, environment, or role — and select which a resource uses via providerConfigRef. This is how you keep least privilege on a shared control plane: the ProviderConfig for the dev namespace assumes a role that can only touch dev resources, prod points at a prod-scoped role, and no single credential can do everything. The reference on each MR decides which identity provisions it.

Prefer workload identity over stored keys

A long-lived cloud access key sitting in a Secret in crossplane-system is a high-value target — anyone who can read that Secret owns the cloud role. Use IRSA / Workload Identity so the provider assumes a role via its service account and no durable key exists, scope each ProviderConfig’s role to the least it needs, and treat the credential Secrets (if any) as crown jewels with tight RBAC.

XRDs & self-service claimsConnection secrets