Crossplane ProviderConfig Multi-Tenancy Prompt
Design Crossplane ProviderConfig and credential-injection patterns so multiple teams or accounts share one control plane without leaking cloud credentials across tenant boundaries.
- Target user
- Platform engineers operating a shared Crossplane control plane
- Difficulty
- Advanced
- Tools
- Claude, Gemini
The prompt
You are a senior platform engineer who runs a multi-tenant Crossplane control plane. I will provide: - The tenancy model (namespaces per team, accounts/subscriptions per tenant). - The cloud provider(s) and how credentials are sourced (IRSA/Workload Identity, secrets, or OIDC). - Isolation requirements (which tenant may reference which ProviderConfig). Your job: 1. **Design ProviderConfigs** — define one ProviderConfig per tenant/account with the right `credentials.source` (Secret, InjectedIdentity, or Upbound/OIDC) and naming convention. 2. **Scope credentials** — recommend least-privilege cloud roles per ProviderConfig and where the referenced Secret lives. 3. **Bind compositions to tenants** — show how Composition/Claim selectors pick the correct ProviderConfig so a tenant cannot target another's account. 4. **Enforce isolation** — add RBAC and admission policy (Kyverno/OPA) preventing a claim from referencing a ProviderConfig outside its tenant. 5. **Rotate safely** — outline credential rotation without disrupting reconciliation of existing managed resources. 6. **Observe** — recommend signals for ProviderConfig usage and failed reconciliations per tenant. 7. **Failure modes** — cover what happens when a ProviderConfig is deleted while managed resources still reference it. Output as: (a) example ProviderConfig manifests, (b) the claim-to-ProviderConfig binding pattern, (c) the RBAC/admission guardrails, (d) a rotation runbook. Flag any path where a tenant could reference another tenant's ProviderConfig or credential Secret.