Self-Service Cloud Infrastructure with Crossplane

How to give every service its own least-privilege cloud identity and let application teams self-serve app-scoped cloud resources through a GitOps claim API — built on in-cluster Crossplane v2 alongside a hard Terraform type-split. Eight days from the shared-identity bottleneck through tool choice, the ownership boundary, standing up the control plane, the XRole claim and capability profiles, GitOps safety, and a phased pilot-to-production rollout.

1. 01The App-Scoped Infrastructure BottleneckApplication code ships in minutes through self-service GitOps; the cloud infrastructure that code depends on still crawls through a platform team's pull-request queue. This first day frames the two problems that motivate the whole course — a *velocity* problem (every app-scoped bucket, role, or identity is a platform round-trip) and a *security* problem (every service shares one cloud identity, so the blast radius is the whole fleet) — and the single idea that fixes both: let teams **claim** their own app-scoped cloud resources declaratively, and give each service its **own least-privilege cloud identity**.Published 29 Jul 20267 sections
2. 02Choosing the Control Plane: Crossplane vs KCC vs ACKThree mature tools can provision cloud resources from inside Kubernetes — Crossplane, the GCP Config Connector (KCC), and the AWS Controllers for Kubernetes (ACK). Picking one is not a maturity contest; all three are production-grade. It is a question of *what you are actually building*. This day compares them across the six dimensions that matter for a two-cloud, GitOps, app-scoped-only model, and lands on the decision — including the one premise that flips the answer.Published 30 Jul 20269 sections
3. 03Drawing the Boundary: The Hard Type-Split with TerraformThe whole model rests on one line: which cloud resources the in-cluster controller may own, and which stay with Terraform. Draw that line loosely and the two systems fight over the same objects; draw it as an unambiguous, enforceable test and they coexist cleanly forever. This day turns "foundation vs app-scoped" into a single-axis rule, works the genuinely hard case (a grant that crosses the line), and shows how to keep the boundary honest as the platform grows.Published 31 Jul 20267 sections
4. 04Standing Up Crossplane v2: Controller, Providers, and IdentityBefore any team can claim a resource, the control plane has to exist and be trusted by both clouds. This day builds the platform layer: the Crossplane v2 core, the AWS and GCP provider packages, their provider configs, and — the part that actually gates everything — the **controller identity** each cloud must trust to let Kubernetes mint IAM. It is deployed as ordered GitOps charts and switched on for a two-cluster pilot, one GKE and one EKS.Published 01 Aug 20267 sections
5. 05The XRole Claim API: XRD, Composition, and the Function PipelineThis is the day the platform becomes a product. Everything so far — controller, providers, boundary — exists so that an app team can write a few lines of YAML and get a per-service cloud identity with exactly the access it needs. This day designs that claim: the `XRole` API a team writes, the per-cluster facts the platform injects, the function pipeline that expands one claim into the right provider resources on either cloud, and the hardening that stops a claim from asking for too much.Published 02 Aug 20269 sections
6. 06Capability Profiles: Verbatim Parity First, Then TrimIf `access` is the only grant surface, then the *catalog of profiles* behind it is where least privilege is actually won or lost. This day designs that catalog: how to package today's messy real-world permissions into named profiles without dropping anything, how to split them so you can tighten access later without breaking anyone now, and how to make one list of profiles the single source of truth for the composition, the schema validation, and the admission policy at once.Published 03 Aug 20267 sections
7. 07Making It Safe in GitOps: Health, Deletion, and AdmissionA claim API that provisions real cloud IAM through a GitOps engine is powerful and, unguarded, dangerous. This day covers the three safety systems that make it trustworthy in production: honest health reporting (so a failed cloud operation shows red, not a false green), type-dependent deletion (so a config slip can't destroy data), and admission-time guardrails (so no claim or raw resource can escape the allowlist). None of these is optional; each closes a failure mode the others can't see.Published 04 Aug 20266 sections
8. 08Rolling Out: Pilot → Cutover → Prod Without a Big BangA system this central can't arrive all at once. This final day is the rollout: a three-phase plan that separates *standing the platform up* from *cutting services over* from *going to production*, the accepted risks you carry into each phase and how you fence them, and the definition of done that says when it's actually finished — a quantified velocity win, not just "it runs."Published 05 Aug 20267 sections