Crossplane vs Terraform: Provisioning S3 Buckets from Kubernetes Without Losing Control

Every platform team eventually hits the same wall: application teams need an S3 bucket and a Postgres instance, and they need them today. The options are usually "open a ticket" (slow), "give them Terraform access" (scary), or "build a self-service API" (expensive). Crossplane positions itself as the third option, implemented with CRDs you already know how to operate.

This article walks through a concrete case — an S3 bucket plus an RDS instance, exposed to developers as a single namespaced Claim — and compares it honestly with the terraform plan/apply workflow. By the end you should be able to write an XRD, a Composition, hand a Claim to your teams, and know when Crossplane is not the right tool.

Context: the lifecycle ownership problem

Terraform's model is a transaction: you compute a diff against state, a human reviews it, and the apply executes. It is excellent for "build this VPC once, review every change carefully". It is mediocre at "fifty teams create and destroy buckets every week", because each of those operations needs a pipeline run, a state lock, a reviewer, and a merge.

Crossplane inverts the model. You install controllers in your cluster that own AWS resources as Kubernetes objects. There is no plan step and no state file: the desired state is the Kubernetes object, the actual state is the AWS API, and a reconciliation loop closes the gap — forever, every few minutes.

That difference drives everything else:

Neither wins outright. Crossplane's auto-correction is a feature when someone fat-fingers a bucket policy in the console, and a liability when an SRE legitimately needs a temporary manual change. Terraform's plan gate is a feature for a production VPC and pure friction for the 400th dev bucket.

Installing Crossplane and the AWS provider

Crossplane runs fine on OpenShift; the Upbound provider images run as UID 65532 and are compatible with the restricted-v2 SCC, so no SCC exception is needed for the controllers themselves.

helm repo add crossplane-stable https://charts.crossplane.io/stable helm repo update helm install crossplane crossplane-stable/crossplane \ --namespace crossplane-system --create-namespace \ --version 1.18.2 --wait kubectl get pods -n crossplane-system 

The monolithic provider-aws is gone. Upbound ships one provider per service family, which keeps the CRD count sane — installing the full AWS provider used to create ~900 CRDs and melt small API servers.

apiVersion: pkg.crossplane.io/v1beta1 kind: DeploymentRuntimeConfig metadata: name: aws-irsa spec: serviceAccountTemplate: metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/crossplane-provider-aws --- apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: provider-aws-s3 spec: package: xpkg.upbound.io/upbound/provider-aws-s3:v1.21.0 runtimeConfigRef: name: aws-irsa --- apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: provider-aws-rds spec: package: xpkg.upbound.io/upbound/provider-aws-rds:v1.21.0 runtimeConfigRef: name: aws-irsa --- apiVersion: pkg.crossplane.io/v1 kind: Function metadata: name: function-patch-and-transform spec: package: xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.8.2 

Credentials come from the pod identity, never from a static key:

apiVersion: aws.upbound.io/v1beta1 kind: ProviderConfig metadata: name: default spec: credentials: source: IRSA 

kubectl get providers kubectl get providerconfig.aws.upbound.io 

If you are not on EKS/ROSA with STS, use source: WebIdentity with an OIDC-federated role, or at worst a Secret — but see the security section.

Defining the API your teams will consume: the XRD

The CompositeResourceDefinition (XRD) is the contract. It generates two CRDs: a cluster-scoped Composite Resource (XR) and a namespaced Claim. Developers only ever touch the Claim.

Design rule: the XRD schema should expose product decisions, not AWS fields. If a developer can set blockPublicAcls: false, you have built a thin wrapper around the AWS API and gained nothing.

apiVersion: apiextensions.crossplane.io/v1 kind: CompositeResourceDefinition metadata: name: xobjectstores.platform.acme.io spec: group: platform.acme.io names: kind: XObjectStore plural: xobjectstores claimNames: kind: ObjectStore plural: objectstores defaultCompositionRef: name: objectstore-aws versions: - name: v1alpha1 served: true referenceable: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: parameters: type: object properties: region: type: string enum: ["eu-west-1", "eu-west-3"] versioning: type: boolean default: true dataClassification: type: string enum: ["internal", "confidential"] default: internal required: ["region"] required: ["parameters"] status: type: object properties: bucketName: type: string 

Three fields. No ACLs, no encryption toggle, no public access knobs — those are decided by the platform, in the Composition.

The Composition: where the opinions live

A Composition maps one XR to N managed resources. Since Crossplane 1.17, Compositions run as a function pipeline; function-patch-and-transform reproduces the classic patching behaviour.

apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: objectstore-aws spec: compositeTypeRef: apiVersion: platform.acme.io/v1alpha1 kind: XObjectStore mode: Pipeline pipeline: - step: patch-and-transform functionRef: name: function-patch-and-transform input: apiVersion: pt.fn.crossplane.io/v1beta1 kind: Resources resources: - name: bucket base: apiVersion: s3.aws.upbound.io/v1beta1 kind: Bucket spec: forProvider: region: eu-west-3 tags: managed-by: crossplane patches: - type: FromCompositeFieldPath fromFieldPath: spec.parameters.region toFieldPath: spec.forProvider.region - type: FromCompositeFieldPath fromFieldPath: spec.parameters.dataClassification toFieldPath: spec.forProvider.tags[classification] - type: ToCompositeFieldPath fromFieldPath: metadata.annotations[crossplane.io/external-name] toFieldPath: status.bucketName - name: block-public-access base: apiVersion: s3.aws.upbound.io/v1beta1 kind: BucketPublicAccessBlock spec: forProvider: blockPublicAcls: true blockPublicPolicy: true ignorePublicAcls: true restrictPublicBuckets: true bucketSelector: matchControllerRef: true patches: - type: FromCompositeFieldPath fromFieldPath: spec.parameters.region toFieldPath: spec.forProvider.region - name: encryption base: apiVersion: s3.aws.upbound.io/v1beta1 kind: BucketServerSideEncryptionConfiguration spec: forProvider: rule: - applyServerSideEncryptionByDefault: - sseAlgorithm: aws:kms bucketKeyEnabled: true bucketSelector: matchControllerRef: true patches: - type: FromCompositeFieldPath fromFieldPath: spec.parameters.region toFieldPath: spec.forProvider.region - name: versioning base: apiVersion: s3.aws.upbound.io/v1beta1 kind: BucketVersioning spec: forProvider: versioningConfiguration: - status: Enabled bucketSelector: matchControllerRef: true patches: - type: FromCompositeFieldPath fromFieldPath: spec.parameters.region toFieldPath: spec.forProvider.region - type: FromCompositeFieldPath fromFieldPath: spec.parameters.versioning toFieldPath: spec.forProvider.versioningConfiguration[0].status transforms: - type: convert convert: toType: string - type: map map: "true": Enabled "false": Suspended 

matchControllerRef: true is the Crossplane equivalent of aws_s3_bucket.this.id in HCL: it resolves the reference to the sibling resource created by the same XR, without you knowing the generated bucket name.

Validate the rendering before applying anything to the cluster — this is the closest thing Crossplane has to terraform plan:

crossplane render examples/claim.yaml composition.yaml functions.yaml 

The Claim: what developers actually write

apiVersion: platform.acme.io/v1alpha1 kind: ObjectStore metadata: name: invoices namespace: team-billing spec: parameters: region: eu-west-3 dataClassification: confidential 

kubectl apply -f claim.yaml kubectl get objectstore -n team-billing # NAME SYNCED READY CONNECTION-SECRET AGE # invoices True True 62s 

Four lines of YAML, in their own namespace, gated by their own RBAC. No AWS credentials, no state backend, no pipeline.

Day-2 operations: observing the fleet

This is where Crossplane's Kubernetes-native nature pays off. Every AWS object is a queryable resource:

# Every managed resource in the cluster, all providers kubectl get managed # Only S3, with sync/ready conditions kubectl get bucket.s3.aws.upbound.io # Anything not reconciling kubectl get managed -o json \ | jq -r '.items[] | select(.status.conditions[]? | select(.type=="Synced" and .status!="True")) | "\(.kind)/\(.metadata.name)"' # Full ownership tree from the claim down crossplane beta trace objectstore.platform.acme.io/invoices -n team-billing 

Drift correction is the headline difference. Suspend versioning out of band and watch it come back:

aws s3api put-bucket-versioning --bucket invoices-xyz123 \ --versioning-configuration Status=Suspended # within the poll interval (default 10m, --poll-interval on the provider) kubectl describe bucketversioning.s3.aws.upbound.io | grep -A3 Events 

With Terraform you would learn about this at the next terraform plan -detailed-exitcode in a nightly job — assuming you built that job.

The escape hatch when you do need a manual change: managementPolicies: ["Observe"] on the managed resource freezes Crossplane into read-only mode for that object.

Adding RDS: where it gets real

Buckets are easy. RDS exposes the parts that matter: credentials and deletion safety.

 - name: db base: apiVersion: rds.aws.upbound.io/v1beta1 kind: Instance spec: deletionPolicy: Orphan forProvider: engine: postgres engineVersion: "16.3" instanceClass: db.t4g.small allocatedStorage: 20 storageEncrypted: true publiclyAccessible: false skipFinalSnapshot: false autoGeneratePassword: true passwordSecretRef: namespace: crossplane-system name: invoices-db-master key: password writeConnectionSecretToRef: namespace: crossplane-system name: invoices-db-conn 

autoGeneratePassword: true makes the provider generate the password and store it in the referenced Secret — the password never transits through Git or a Composition. The connection secret (endpoint, port, username, password, attribute.*) is then propagated to the claim's namespace via the XRD's connectionSecretKeys and the claim's writeConnectionSecretToRef.

deletionPolicy: Orphan is non-negotiable for stateful resources. The default is Delete, which means kubectl delete objectstore invoices destroys a production database. Pair it with the Usage resource (--enable-usages) to block deletion while a consumer exists.

When to use which

Use Crossplane when the resource is high-volume and templated (buckets, queues, databases, IAM roles for apps), when consumers are developers who should not learn HCL, when drift correction is a compliance requirement, and when the consumer is already a Kubernetes workload that wants its credentials as a Secret.

Stay on Terraform for the bootstrap layer (accounts, VPCs, the EKS/ROSA cluster that runs Crossplane — you cannot have the cluster manage its own existence), for anything where a human must approve the exact diff before execution, for multi-cloud one-shots, and when your team's operational maturity on Kubernetes is low. A broken Crossplane provider is a debugging session in controller logs, not a Terraform error message.

The two coexist well: Terraform builds the landing zone and the cluster, Crossplane serves the application-level resources on top.

Security best practices

• No static AWS keys. Use IRSA / EKS Pod Identity / WebIdentity. If you absolutely must use a Secret, source it from External Secrets Operator or Vault and rotate it; never commit it.
• Least privilege per provider. provider-aws-s3 and provider-aws-rds get separate DeploymentRuntimeConfigs and separate IAM roles. The S3 provider has no business calling rds:DeleteDBInstance.
• Multi-tenant isolation via ProviderConfig. One ProviderConfig per environment/account, each referencing a different role. Set providerConfigRef in the Composition, never from the Claim, and enforce it with a Kyverno or ValidatingAdmissionPolicy rule so no one creates raw managed resources directly.
• RBAC on Claims, not on XRs. Developers get create/get/list/delete on objectstores in their namespace only. Nobody outside the platform team touches Composition, CompositeResourceDefinition, or *.aws.upbound.io.
• Encode guardrails in the Composition. Public access block, KMS encryption, publiclyAccessible: false, mandatory tags — hardcoded in the base, not exposed as parameters.
• deletionPolicy: Orphan + Usages on every stateful resource, with an AWS-side backstop (SCP or termination protection).
• Protect connection secrets. Encrypt etcd at rest, keep provider-level secrets in crossplane-system, and restrict get on Secrets in tenant namespaces.
• Verify packages. Pin provider and function images by digest, mirror them into your internal registry, and enable Crossplane's signature verification rather than pulling :latest from the public internet.
• Audit. Every change is a Kubernetes API call: ship audit logs, and alert on managed resources stuck in Synced=False — that is usually an IAM denial.

Key takeaways

• Crossplane replaces the plan/apply transaction with a continuous control loop. You trade previewability for self-healing; choose per resource class, not per company.
• The XRD is your product API. Expose decisions (region, classification), not AWS fields. If the Claim is 40 lines long, the abstraction has failed.
• Compositions are where your security policy becomes executable: encryption, public access block, and tags are hardcoded, not optional.
• kubectl get managed and crossplane beta trace give you fleet-wide infrastructure visibility that no Terraform state layout provides.
• deletionPolicy: Orphan on anything stateful, from day one. The default will eventually delete a production database.
• Keep Terraform for the bootstrap layer and for changes that genuinely need a human reading a diff. Crossplane is a self-service platform, not a Terraform replacement.