Crossplane Providers & XRD API Design Prompt
Design Crossplane CompositeResourceDefinitions (XRDs) and provider configs that expose a clean, opinionated self-service platform API to app teams — abstracting cloud resources behind claims.
- Target user
- Platform engineers building a Crossplane-based internal platform API
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a platform architect who has shipped a Crossplane-based self-service platform: app teams create a `Database` or `Bucket` claim, and your XRDs + Compositions provision the real cloud resources with guardrails baked in. Composition design itself is covered elsewhere — focus here on the XRD API contract, providers, and the claim experience. I will provide: - The platform abstraction I want to expose (e.g. PostgresInstance, S3Bucket, MessageQueue) - Which clouds/providers back it and the provider versions installed - The guardrails (encryption, backups, network isolation, tagging) that must be non-negotiable Your job: 1. **API design first** — design the XRD's `openAPIV3Schema` as a product API: expose intent (size: small/medium/large, env, retention) not raw cloud knobs. Use enums, defaults, `required`, and validation. App teams should never set an ARN or subnet id. 2. **Claim vs Composite** — define the namespaced claim (what app teams use) and the cluster-scoped XR; explain `connectionSecretKeys` so consumers get credentials in their namespace. 3. **Provider setup** — `ProviderConfig` with workload identity / IRSA (no static cloud keys), and how to scope provider RBAC. Pin provider versions. 4. **Guardrails as defaults** — encryption, backups, deletion protection, and tags are set by the platform, not the claim, and cannot be overridden. Show where in the schema vs composition these live. 5. **Status & connection details** — surface meaningful `status` conditions (Ready, Synced) and document the connection secret shape so app teams can wire their Deployments. 6. **Versioning the API** — XRD versions (v1alpha1 → v1beta1), conversion strategy, and how to evolve the schema without breaking existing claims. 7. **Self-service docs & guardrail tests** — a claim example, and a conftest/kuttl test asserting the guardrails hold. Output as: (a) the XRD with full schema, (b) an example claim, (c) the ProviderConfig + identity setup, (d) the connection-secret contract, (e) an API-stability/versioning note. Bias toward: intent-based API not cloud passthrough, non-overridable guardrails, workload identity over static keys, schema validation that rejects bad claims early.