How do you manage Crossplane ProviderConfigs for multi-account and multi-region setups?

In enterprise environments, infrastructure rarely lives in a single cloud account or region. The payments-api may run in a PCI-compliant AWS account, the user-auth-service may live in a separate identity account, and the order-processing-service may span multiple regions for disaster recovery. Crossplane ProviderConfigs are the mechanism that maps each managed resource to the correct cloud account and credentials, enabling a single Crossplane control plane to manage infrastructure across dozens of accounts and regions from one Kubernetes cluster.

A ProviderConfig is a cluster-scoped custom resource that each Crossplane provider installs. For the AWS provider, the ProviderConfig specifies how to authenticate, whether through static credentials stored in a Kubernetes Secret, IAM Roles for Service Accounts (IRSA) when running on EKS, or AssumeRole chains for cross-account access. The most production-ready pattern is IRSA combined with AssumeRole. The Crossplane pod runs with a base IAM role that has permission only to assume other roles, and each ProviderConfig specifies a target role ARN in a different AWS account. When the checkout-service team requests a DynamoDB table in the commerce account, the managed resource references providerConfigRef with the name aws-commerce-account, and the provider assumes the appropriate role to create resources in that account.

For multi-region setups, the approach depends on whether the provider supports a region field directly on the managed resource or requires separate ProviderConfigs. The AWS Upbound provider allows setting spec.forProvider.region on each managed resource, so a single ProviderConfig can manage resources in any region. However, some organizations prefer creating region-specific ProviderConfigs like aws-prod-us-east-1 and aws-prod-eu-west-1 for additional isolation and to enforce regional guardrails through RBAC. The inventory-sync service might need DynamoDB global tables spanning three regions, and the Composition creates three managed resources each referencing a different region-specific ProviderConfig. GCP providers work similarly with project-scoped ProviderConfigs, where each config points to a different GCP project and uses Workload Identity Federation for keyless authentication from a GKE-hosted control plane.

Credential management is the most security-critical aspect of ProviderConfigs. Static credentials stored in Kubernetes Secrets are the simplest approach but create rotation burdens and blast-radius risks. If a Secret containing AWS access keys for the production account is compromised, the attacker gains full infrastructure access. IRSA eliminates long-lived credentials entirely by exchanging Kubernetes service account tokens for temporary AWS STS credentials. For cross-account scenarios, the ProviderConfig specifies an assumeRoleChain where the base role assumes an intermediate role in a networking account, which then assumes a final role in the target account. This chain pattern is common in organizations using AWS Control Tower or Landing Zone architectures where the checkout-service infrastructure spans a shared-services account for networking and a workload account for compute resources.

Operational best practices include naming ProviderConfigs with a consistent convention like provider-environment-account-region, applying labels for discoverability, and using Crossplane RBAC to restrict which teams can reference which ProviderConfigs. A namespace-scoped Claim should not be able to provision resources in the production payments account by simply changing a providerConfigRef name. Platform teams enforce this through Composition-level providerConfigRef settings that are not patchable from the claim, or through admission webhooks and OPA Gatekeeper policies that validate providerConfigRef values against team membership. Monitoring ProviderConfig health is also essential because a credential rotation that invalidates a ProviderConfig silently breaks all reconciliation for resources using that config, causing drift to go undetected until the user-auth-service database fails to apply a critical security patch.