The App-Scoped Infrastructure Bottleneck

# Software placement: which worker machine is executing the Pod?
kubectl -n document-processing get pod -l app=document-export-service \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IP:.status.podIP'

# Hardware budget exposed through the Node object.
kubectl get node -o custom-columns='NODE:.metadata.name,CPU:.status.allocatable.cpu,MEMORY:.status.allocatable.memory'

An in-cluster controller such as Crossplane is consequently just another set of Pods using node CPU, memory, and networking, plus permissions to watch and update Kubernetes objects. Its special power comes from its reconciliation logic and credentials, not from special hardware. It reads desired state from the API, calls an external cloud API, and writes observed status back. If its Pod disappears, Kubernetes can start a replacement; if its permissions or provider credentials are wrong, it may run perfectly at the hardware level while reconciliation remains Ready=False.

Move two is cloud-side identity separation: the cloud IAM principal behind that ServiceAccount also becomes per-service. This last link is the one the course changes.

What a Kubernetes ServiceAccount actually means

A Kubernetes ServiceAccount is a named, non-human identity for software. It is an API object inside one namespace, so document-processing/document-export-service and sandbox/document-export-service are two different identities even though their final names match. A Pod does not become a Linux user or a cloud account when it selects one. Kubernetes records that the Pod is acting as a subject with the canonical name system:serviceaccount:document-processing:document-export-service, and can project a short-lived, rotating token into the Pod as evidence of that identity. If spec.serviceAccountName is omitted, Kubernetes assigns the namespace's default ServiceAccount. Kubernetes ServiceAccounts

Keep four things separate:

The ServiceAccount supplies identity, not permission by itself. A RoleBinding can authorize that identity against the Kubernetes API. Separately, IRSA on AWS, EKS Pod Identity, or Workload Identity Federation on GCP can trust the same namespaced identity and deliver short-lived cloud credentials. AWS describes the mapping as a Kubernetes ServiceAccount to an IAM identity; GCP represents the KSA as a principal in a workload identity pool. Amazon EKS workload identities GKE Workload Identity Federation

The smallest useful model is therefore workload -> Kubernetes identity -> authorised API:

The API server creates the ServiceAccount object; the ServiceAccount admission controller and kubelet arrange the projected credential; the API server authenticates its signature, expiry, bound object, and audience; then RBAC makes a separate authorization decision. Creating the identity consumes negligible data-plane hardware by itself. The observable proof is the Pod's selected ServiceAccount, the token projection, and a positive or denied API request matching the intended RBAC policy.

# Identity proof: which ServiceAccount did the Deployment give its Pods?
kubectl -n document-processing get pod -l app=document-export-service \
  -o jsonpath='{.items[0].spec.serviceAccountName}{"\n"}'

# Authorization proof: may that exact identity read Secrets in its namespace?
kubectl auth can-i get secrets -n document-processing \
  --as=system:serviceaccount:document-processing:document-export-service

The second diagram adds the cloud boundary without changing the Kubernetes identity path:

The cloud provider, not Kubernetes RBAC, interprets the final permission. The bridge validates or exchanges workload identity evidence, the cloud security-token service issues temporary credentials, and the SDK uses them for a provider API call. The request then consumes application CPU and network plus the cloud service's storage or compute. The proof must come from both sides: document-export-service succeeds against its own export bucket, while a neighbouring ServiceAccount receives AccessDenied.

Before: an implicit Kubernetes identity ends at one shared cloud role

In the unsafe starting point, each Pod silently receives the namespace's default ServiceAccount because the Deployment never names one. That identity may then be mapped—directly or through node credentials—to the fleet's shared cloud role. The default ServiceAccount is not inherently privileged; the danger is the broad cloud identity behind it.

# Before: omission means "use document-processing/default".
apiVersion: apps/v1
kind: Deployment
metadata:
  name: document-export-service
  namespace: document-processing
spec:
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/document-export-service:1.4.0
      # No serviceAccountName: Kubernetes assigns document-processing/default.

Compromising either Pod now exposes the same role. The role must carry the union of permissions, so the identity boundary between the services exists in Kubernetes but disappears at the cloud boundary.

After: an explicit identity maps to one least-privilege cloud role

The safe shape creates and selects a dedicated ServiceAccount. The claim shown later asks the platform to mint a cloud identity whose trust subject is exactly system:serviceaccount:document-processing:document-export-service; it does not grant every ServiceAccount in document-processing access.

# After: the workload identity exists explicitly in the same namespace as the Pod.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: document-export-service
  namespace: document-processing
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: document-export-service
  namespace: document-processing
spec:
  template:
    metadata:
      labels:
        app: document-export-service
    spec:
      serviceAccountName: document-export-service # selects document-processing/document-export-service, not document-processing/default
      containers:
        - name: api
          image: registry.example.com/document-export-service:1.4.0

The manifest alone does not create cloud permission. It creates the stable Kubernetes subject that the binding can trust. The later XRole claim creates the other half: a distinct cloud identity, an allowlisted permission policy, and an exact trust relationship back to this ServiceAccount. Decision rule: use one ServiceAccount per distinct permission boundary, always select it explicitly, and treat Kubernetes RBAC and cloud IAM as two independent authorization systems that happen to trust the same workload identity.

The binding mechanism from ServiceAccount to cloud identity already exists; it is simply pointed at one shared identity. Filling that binding with a distinct least-privilege identity per service is the concrete step that finishes the arc — and doing it through a self-service claim is what keeps it from re-creating the bottleneck. Rule of thumb: don't rebuild identity plumbing you already have; find the last shared link in the chain and make that per-service.

Terraform keeps the foundation; the self-service layer takes only the app-scoped tier. The two never own the same cloud object. That clean split is the precondition for everything that follows, and Day 03 turns it into an enforceable test. Rule of thumb: self-service is safe exactly where the resource's lifecycle matches one app's lifecycle; the moment a resource is shared or perimeter-level, it belongs back in the gated foundation.

Start with the ownership question, not the resource type

"Bucket" is not a useful classification by itself. A bucket holding one service's generated document exports may be app-scoped; a bucket holding company-wide audit logs is foundation. The cloud API is the same, but the ownership and failure consequences are not.

The vertical line in the diagram is the important one: a lifecycle boundary, not a permission free-for-all. An app team can request a resource only on its side of the line. The platform team still decides the cloud account, region, encryption defaults, network placement, provider credentials, and which kinds of claim are available. A claim is a request through a narrow, platform-authored API; it is not cloud-console access.

What the foundation code continues to own

Here is a deliberately small Terraform fragment for an AWS foundation. It creates the shared network and exposes its ID as an output. It does not create an application's bucket or IAM role.

# foundation/main.tf -- platform-owned and reviewed separately
resource "aws_vpc" "platform" {
  cidr_block           = "10.40.0.0/16"
  enable_dns_hostnames = true

  tags = {
    "platform.example.com/owner" = "platform"
    "platform.example.com/tier"  = "foundation"
  }
}

resource "aws_kms_key" "shared" {
  description         = "Shared platform encryption key"
  enable_key_rotation = true
}

output "platform_vpc_id" {
  value = aws_vpc.platform.id
}

What makes this foundation: Terraform reads this declaration, records the VPC and KMS key in its state, and reconciles those long-lived cloud objects. The VPC consumes provider network capacity; the key becomes part of the shared encryption perimeter. terraform plan must show only these foundation objects, and terraform state list must contain aws_vpc.platform and aws_kms_key.shared. The state-to-object binding is why a second reconciler must never manage the same object; Terraform's own model expects one configured resource instance for each remote object. Terraform state documentation

The output is an intentional one-way interface: later platform configuration can refer to a foundation fact such as the VPC ID, but an application claim cannot alter the VPC. This is the same shape as an operating system exposing a file handle without giving a process permission to reconfigure the disk controller.

What a team is allowed to request

Now take a service named document-export-service. It renders customer documents into downloadable formats and stores the resulting artifacts in its own bucket. The team commits a small XRole claim beside its Kubernetes workload. XRole is a custom API supplied by the platform; Day 05 defines its schema and Composition. The claim has no account ID, VPC ID, raw IAM statement, or provider credential because those are foundation facts and platform decisions.

# apps/document-export-service/identity.yaml -- application-team owned
apiVersion: platform.example.com/v1alpha1
kind: XRole
metadata:
  name: document-export-service
  namespace: document-processing
  labels:
    platform.example.com/owner: document-platform-team
spec:
  owner: document-platform-team
  serviceName: document-export-service
  serviceAccountName: document-export-service
  access:
    - export-storage-read-write # named, reviewed capability; not raw IAM JSON

The same workload selects its exact Kubernetes ServiceAccount:

# apps/document-export-service/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: document-export-service
  namespace: document-processing
spec:
  template:
    spec:
      serviceAccountName: document-export-service # matches the claim's trust subject
      containers:
        - name: api
          image: registry.example.com/document-export-service:1.4.0

What this changes in reality: GitOps applies the XRole object to the Kubernetes API server. Crossplane observes that desired state and its platform-authored Composition creates a cloud IAM identity whose trust is bound to document-processing/document-export-service; it expands export-storage-read-write into only the permitted storage actions. The pod then obtains cloud credentials through its workload-identity binding, rather than inheriting a fleet-wide credential. No VPC, shared key, DNS zone, or cloud account is created or edited by either manifest.

The hardware effect is indirect but real: the controller makes provider API calls that store an IAM principal and policy in the cloud control plane; the application pod uses CPU and network only when it exchanges its Kubernetes identity for short-lived credentials and calls the bucket service. Evidence is not a green Git commit: inspect the claim's readiness and test the service's actual access.

# Healthy state: the controller has created and observed the app identity.
kubectl -n document-processing get xrole document-export-service \
  -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}{"\n"}'

# Runtime proof: this pod can reach only its own app-scoped storage path.
kubectl -n document-processing exec deploy/document-export-service -- \
  aws s3api head-bucket --bucket xp-app-prod-document-processing-document-export

Expected evidence is True for the claim's Ready condition and a successful bucket check from document-export-service. document-preview-service should receive AccessDenied for that bucket. That negative result is a success condition: it proves the identity is not shared.

One request path, two separate ownership planes

The app team gets a faster path without receiving the platform team's blast radius:

The first path is deliberately unchanged: Terraform owns and changes the foundation. The second path is constrained: the team owns the request, while the platform owns the template that interprets it. That division is what lets the platform set mandatory tags, a fixed cloud account, a permissions boundary, and an approved region without asking each team to understand or safely reproduce them.

This fuller view adds two facts without moving the boundary. Git provides review and desired state; the Composition turns only approved claim fields into provider resources. The dotted edge is intentionally one-way. Foundation data may inform the template, but the claim never reaches back to mutate foundation objects.

A bounded failure and the recovery loop

Use a deliberately invalid claim to prove that the boundary is enforced before introducing it to a real service. This claim asks for a raw permission instead of one of the catalog's named capabilities:

# This must be rejected: raw provider permissions are not part of the claim API.
apiVersion: platform.example.com/v1alpha1
kind: XRole
metadata:
  name: document-export-unrestricted
  namespace: document-processing
spec:
  owner: document-platform-team
  serviceName: document-export-service
  serviceAccountName: document-export-service
  access:
    - "s3:*" # invalid: not an allowlisted capability profile

The API server or claim validation should reject this object, or the claim should settle Ready=False with a clear validation reason, depending on where the policy runs. Either way, verify two things: no IAM role was created for document-export-unrestricted, and Terraform's state remains unchanged. Correct the claim to the named capability, let GitOps reconcile again, and verify Ready=True. This is the essential control loop: declare, observe rejection, correct, reconcile, verify.

Edge cases that return to Terraform

The safest classification is conservative. A service-specific cache is normally app-scoped; a Redis cluster shared by checkout, catalogue, and recommendations is foundation even if one team originally requested it. Likewise, an app role can be self-service, but a policy on a shared KMS key remains Terraform-owned because the key is a foundation object. The app requests access; the platform grants it from the foundation side. Day 03 makes that cross-boundary case enforceable.

Reusable decision rule: give self-service only to resources that have one application's lifecycle, one application's references, and a narrow platform API. If any of those conditions stops being true, return the object to the gated foundation plane. That preserves the useful promise: app teams move quickly, while the security perimeter stays intentionally boring.