The Problem with Raw Managed Resources
Giving application developers direct access to raw Managed Resources is like giving them root access to AWS. They can create anything, configure it any way they want, and accidentally expose databases to the public internet or create unencrypted storage buckets. Platform teams need a way to offer infrastructure self-service while enforcing organizational standards.
This is exactly the problem that Compositions solve.
The Two-Part Abstraction
Crossplane's composition system has two components that work together:
1. Composite Resource Definition (XRD) — The Interface
An XRD defines a new custom API type. You decide what parameters developers can set and what the schema looks like — a storage size bounded between a sane minimum and maximum, an engine version constrained to a short list of supported values, both required. Everything not exposed in the XRD is hidden — developers can't accidentally misconfigure what they can't see. Defining an XRD creates two new Kubernetes resource types: a cluster-scoped type for platform engineers, and a namespace-scoped Claim type for application developers.
2. Composition — The Implementation
A Composition defines what actually gets created when someone requests a database through that claim type. It maps the user-facing parameters to real cloud resources — the developer's requested storage size and engine version get patched into the underlying RDS instance's own spec — while everything security-relevant (encryption enabled, public access disabled) is hardcoded directly into the Composition with no patch and no override path. There is no way for a developer to accidentally create an unencrypted or publicly exposed database, because that knob simply isn't wired to anything they can touch.
The Developer Experience
An application developer creates a database by applying a Claim — a handful of lines naming the namespace, a storage size, and an engine version. That's it. The developer doesn't know about RDS instance classes, subnet groups, security groups, parameter groups, or encryption settings. The platform team has encoded all of that organizational knowledge into the Composition. The developer gets a self-service experience; the platform team gets guaranteed compliance.
Composition Selectors: Environment-Aware Infrastructure
A single XRD can have multiple Compositions — one for AWS, one for GCP, one for a local development environment using a simple container. The Composition to use is selected via labels matching against the provider and environment the claim is destined for. This enables a single PostgresDB claim type to provision a real RDS instance in production, a Cloud SQL instance in a GCP environment, and a local PostgreSQL container in development — all from the same developer-facing API.