What is a Crossplane Composite Resource (XR) and why is it useful?
Quick Answer
A Composite Resource (XR) is a custom, higher-level API resource defined by a platform team that bundles multiple Managed Resources into a single abstraction. It allows application developers to request complex infrastructure setups, like a database with networking and security groups, through a single simplified resource rather than managing each cloud component individually.
Detailed Answer
Imagine ordering a combo meal at a restaurant instead of ordering each item separately. You say 'I want combo number three,' and the kitchen knows that means a burger, fries, and a drink prepared in a specific way. You do not need to know the recipe for each item, the cooking temperature, or which supplier provided the ingredients. The combo meal is the abstraction that hides all the complexity behind a simple choice. In Crossplane, a Composite Resource works the same way: it is a single API object that, when created, triggers the provisioning of multiple underlying cloud resources according to a template defined by the platform team.
A Composite Resource is an instance of a custom API type defined by a CompositeResourceDefinition (XRD). The platform team defines the XRD to specify what parameters developers can configure, such as database size (small, medium, large), region, and engine type, and what parameters are hidden because they are standardized across the organization. When a developer on the order-processing-service team creates an XR, Crossplane looks up the corresponding Composition, which maps the XR's parameters to the specific Managed Resources that need to be created. A single DatabaseInstance XR might create an RDS instance, a security group, a subnet group, a parameter group, and a Kubernetes Secret containing the connection string, all from one simple YAML manifest.
The real power of Composite Resources is the separation of concerns they enable between platform engineers and application developers. Platform engineers define the Compositions, encoding organizational best practices, compliance requirements, and security policies into the infrastructure templates. They decide that every database gets encryption at rest, automated backups, multi-AZ deployment in production, and appropriate tagging for cost allocation. Application developers on the payments-api or checkout-service teams never see these details. They interact with the simplified XR API that exposes only the parameters relevant to their application, like size and region. This is the concept of a platform API or Internal Developer Platform (IDP) built directly into Kubernetes.
Composite Resources also solve the problem of infrastructure consistency across teams. Without XRs, each team would write their own Managed Resource manifests, leading to inconsistent configurations. One team might forget to enable encryption, another might use a deprecated instance class, and a third might skip setting up proper backup retention. With Composite Resources, the platform team controls the template, ensuring that every database provisioned by every team meets the same production standards. If a security audit requires changing the minimum TLS version for all databases, the platform team updates the Composition once, and all new XRs automatically pick up the change.
Composite Resources can be exposed to developers through Claims (XRCs), which are namespace-scoped versions of the cluster-scoped XR. While XRs are cluster-scoped and typically managed by platform teams, Claims are namespaced and designed for application teams. A developer in the inventory-sync namespace creates a DatabaseClaim, which Crossplane translates into a cluster-scoped XR, which in turn creates all the underlying Managed Resources. This namespace scoping integrates naturally with Kubernetes RBAC, letting platform teams control who can provision what infrastructure through standard Kubernetes role bindings rather than building a separate access control system.