Self-Service Cloud Infrastructure: From Ticket Queues to Claims

Enterprise problem: The image-api team cannot ship object uploads without waiting for a platform ticket for a bucket, workload identity, and key access, so a human queue now controls delivery time and obscures who owns each change.

Whole-course context: The course has reached platform operations; today consumes a deployable service definition and turns its infrastructure dependencies into governed, reviewable desired state.

Today’s slice: We design one allowlisted claim that creates image-api’s app-scoped object store and identity while leaving the shared encryption key inside the platform-owned foundation boundary.

End-of-day evidence: A claim revision, reconciliation run, positive object probe, denied escalation probe, deletion-policy result, and immutable evidence ID prove the path.

Still unsolved: Multi-region failover, provider portability, billing allocation, secret rotation, and the application’s own end-user authorization remain outside this slice.

Thesis: Self-service is a constrained product API over infrastructure, not permission to author arbitrary infrastructure: claimed intent enters through policy-controlled reconciliation, and observed cloud reality returns as evidence.

Teams often mistake self-service for direct cloud access, which replaces a ticket bottleneck with unbounded authority. The smallest complete model is safer: intent enters through a narrow claim, policy-controlled reconciliation changes reality, and observed evidence closes the loop.

The thesis is: self-service is a constrained product API over infrastructure, not permission to author arbitrary infrastructure. The loop is complete only when it can observe actual state, expose a reasoned status, and drive a customer decision: proceed, correct the claim, retry, or retire.

For image-api, the first valid outcome is intentionally small: one bucket, one non-human service identity, one approved object-access profile, and proof that the intended service succeeds while a neighbouring service fails. Kubernetes defines a ServiceAccount as a namespaced non-human identity, which makes it a useful workload-side subject rather than a human credential (Kubernetes ServiceAccounts).

If shared perimeter resources enter the same lifecycle as one application, an innocent service deletion can damage every tenant. Classify infrastructure by lifecycle, sharing, and policy ownership before deciding what a claim may create.

A flexible schema can become a disguised cloud console, so the claim must make safe requests easy and unsafe states unrepresentable. Here, a capability profile is a named, versioned bundle of allowed actions and constraints; it is selected from a catalog rather than supplied as raw IAM policy.

apiVersion: platform.example.io/v1alpha1
kind: ServiceInfrastructureClaim
metadata:
  name: image-api
  namespace: media-prod
spec:
  claimId: clm-media-prod-image-api
  ownerTeam: media
  serviceId: svc-image-api
  serviceAccountRef:
    name: image-api
  resources:
    - name: images
      kind: ObjectStore
      deletionPolicy: Retain
  access:
    - capability: object-store-read-write
      resourceRef: images
      profileRevision: "2026-08-01"
    - capability: kms-decrypt
      foundationRef: media-shared-key
      profileRevision: "2026-08-01"

The public API does not expose provider account IDs, arbitrary actions, raw policy JSON, wildcard subjects, or a field that edits the shared key. The schema validates shape; admission validates organization and environment rules; the catalog determines the exact expansion. A new legitimate need changes the catalog through a reviewed platform change rather than adding an escape hatch to one claim.

Crossplane is one implementation option, not the definition of this architecture. Its Composite Resource Definition supplies a custom API schema, while a Composition templates the resources created for that API; current Crossplane documentation describes Compositions as function pipelines that derive desired composed resources from observed and desired state (XRDs, Compositions). The generic design also works with another operator or an external workflow engine if it preserves the same contract and evidence.

One-shot provisioning scripts leave partial resources and silent drift when a provider call fails. A reconciler repeatedly compares desired state with observed state and makes retry-safe changes until they converge; a composition is the platform-authored expansion from the high-level claim to concrete resources.

For image-api, the composition pins the target account and region, stamps organization, service, owner, environment, and claim tags, gives each resource a stable external name, attaches a permissions boundary to the new role, and requests rather than writes the shared-key grant. Crossplane reports separate Synced and Ready conditions for composite resources, so an accepted object is not automatically proof that all composed resources are usable (Crossplane composite-resource conditions).

Idempotency matters at every edge. Retrying after a timeout must look up the stable bucket and role before creating anything; status writes must use the claim generation they observed; evidence records must deduplicate on run_id plus probe name. Otherwise, the loop that should repair partial failure creates duplicate resources or reports stale success.

GitOps adds another control loop: tools such as Argo CD can automatically sync Git differences and can optionally prune removed resources, while self-healing is separately configurable (Argo CD automated sync). Therefore “Git is desired state” is not itself a deletion policy—prune, controller deletion, and external-resource retention must agree explicitly.

Treating absence from Git as permission to destroy everything turns a typo, branch error, or sync mistake into data loss. Retirement must distinguish revocable authority from durable state and must preserve an explicit record of human intent.

The stateful/stateless split is necessary but not sufficient. For the stateless identity, delete only after its grants are revoked and a negative assume-role probe succeeds. For the stateful bucket, remove active access, apply quarantine controls, retain its locator in the lifecycle job, and require a separate purge approval after retention and legal-hold checks.

Kubernetes finalizers delay object removal while a controller completes required cleanup; they do not perform the cleanup themselves and can leave an object stuck if the responsible controller cannot finish (Kubernetes finalizers). Crossplane similarly keeps a managed resource until its provider completes external deletion. Its managementPolicies feature is beta, and current provider support varies: omitting Delete can express retention, but verify that the selected provider implements those semantics before treating the omission as a retention guarantee (Crossplane managed resources). Those mechanisms implement a chosen policy; they do not choose the policy for you.

A shared runtime role makes the compromise of the least secure service equivalent to compromise of the union of every service’s permissions. Per-service identity reduces that blast radius only when both the trust relationship and the permissions are scoped to the exact workload.

On Kubernetes, set spec.serviceAccountName explicitly rather than inheriting the namespace’s default identity. Prefer short-lived projected service-account tokens: Kubernetes documents that TokenRequest tokens expire, rotate, can carry an audience, and can be bound to a Pod, while long-lived Secret-based tokens are not recommended (Kubernetes ServiceAccounts).

For an AWS EKS implementation using IAM Roles for Service Accounts, the role trust policy can require exact aud and sub claims such as system:serviceaccount:media-prod:image-api; replacing the service-account value with a wildcard broadens who can assume the role (Amazon EKS service-account roles). Equivalent workload-identity products should pin cluster or issuer, namespace, service-account name, and intended audience.

The role permission policy answers “what may this identity do?”; the trust policy answers “who may become this identity?” Both must be narrow. Test both directions: image-api can access only its bucket, and thumbnail-worker cannot assume or use the image-api role.

An app-scoped identity that needs a shared key can tempt the claim controller to edit foundation policy directly, erasing the ownership boundary. The safe interface is a grant request: app self-service owns the principal, the foundation service owns policy on its resource, and each side can revoke independently.

AWS distinguishes identity-based policies attached to identities from resource-based policies attached to resources such as S3 buckets and KMS keys; a resource policy specifies who may access that resource (AWS policy types). That supports the ownership rule: the identity adapter owns the app role policy, while the foundation controller owns the shared key’s policy.

Enforce the boundary in layers because no single layer sees the whole system:

Changing identity and reducing permissions simultaneously makes any denial ambiguous and raises rollback risk. Separate identity parity from permission trimming, then remove the shared path only after every service has proved its dedicated path.

Choosing a self-service mechanism without considering service diversity and platform capacity can produce either a rigid catalog nobody can use or an internal cloud console nobody can govern. Select the narrowest interface that covers repeated customer jobs and keeps authoritative ownership explicit.

When reconciliation fails, repeatedly reapplying the claim can amplify damage or hide the ownership fault. Diagnose by locating the last boundary with trustworthy evidence, then test the next interface with the same claim revision and correlation ID.

If policy choices remain implicit, two controllers can make opposite but individually plausible decisions about ownership or deletion. Write these decisions as versioned contracts before the first production claim.

Operators lose time when the only interface is a dashboard that hides revisions and provider correlation IDs. Keep a small command-line path that exposes desired state, controller conditions, composed resources, identity trust, and the terminal evidence envelope without printing credentials.

# Show the exact desired claim and its observed generation.
kubectl -n media-prod get serviceinfrastructureclaim image-api -o yaml

# Read status reasons, composition revision, and referenced resources.
kubectl -n media-prod describe serviceinfrastructureclaim image-api

# Select resources by the stable claim ID, not a mutable display name.
kubectl get managed -A -l platform.example.io/claim-id=clm-media-prod-image-api

# Inspect the exact Kubernetes workload identity binding.
kubectl -n media-prod get serviceaccount image-api -o yaml

# Inspect role trust and the attached permission ceiling; neither command returns credentials.
aws iam get-role --role-name media-prod-image-api
aws iam list-attached-role-policies --role-name media-prod-image-api

# Read one immutable reconciliation-and-probe envelope from the platform API.
platformctl evidence get ev-36-001 --output yaml

The expected evidence is concrete: the claim reports the intended observed generation and pinned profile revision; managed resources carry the same claim ID; the role trust names only the intended issuer, audience, namespace, and service account; the allowed object probe passes; the neighbouring-subject probe fails; and all outputs link to the same immutable run.

For a deletion rehearsal, use a non-production claim with a disposable object plus a retained-object checksum. Prove the grant and role disappear, the bucket remains, the checksum is unchanged, and an unrelated service still passes. Never trial the destructive half of a lifecycle policy against the first production bucket.

The recurring risk is confusing removal of a human ticket with removal of control. Keep these rules available when designing another self-service resource type.

• Self-service is a constrained infrastructure API: claim → policy-controlled reconciliation → observed evidence.
• Classify resources by sharing, lifecycle, and policy ownership; ambiguous or perimeter-defining resources remain foundation-owned.
• Claims select allowlisted, versioned capabilities and never accept arbitrary provider permissions.
• App self-service owns image-api’s bucket and role; the foundation service owns the grant on its shared key.
• Reconciliation must use stable identities, idempotent provider operations, explicit conditions, and runtime probes.
• Stateful resources retain and quarantine on retirement; stateless authority is revoked and deleted; purge is a separate decision.
• One exact workload subject maps to one service role; test both intended access and neighbouring denial.
• Permission boundaries, admission, compositions, controller credentials, foundation grants, and probes are complementary layers.
• Migrate shared identity through parity, cutover, observation, trimming, and final revocation—not one combined leap.
• Measure delivery speed and safety together: readiness time, denials, errors, orphans, revocation time, and retained-state age.

An implementation is not ready because its happy-path claim reconciled once. Review this checklist against an immutable revision and observed positive, negative, failure, and retirement evidence.

• [ ] The claim’s customer job, owning team, service, environment, and stable ID are explicit.
• [ ] Every resource is classified as foundation or app-scoped by lifecycle, sharing, and policy ownership.
• [ ] The schema exposes named capability profiles, not raw IAM policy, provider account selection, or wildcard subjects.
• [ ] The composition pins provider settings, ownership tags, stable external names, deletion policy, and a permission ceiling.
• [ ] Controller cloud credentials cannot mutate foundation resources.
• [ ] image-api has a dedicated role bound to the exact issuer, audience, namespace, and service account.
• [ ] The foundation controller, not the app claim controller, owns the shared-key grant.
• [ ] Positive image-api access and negative neighbouring-service access are observed and linked to one evidence envelope.
• [ ] Partial provider failure retries idempotently and cannot create duplicate resources or stale Ready status.
• [ ] Retirement revokes grants before deleting identity, retains and quarantines the bucket, and requires separate purge approval.
• [ ] Finalizers and GitOps pruning implement the chosen lifecycle policy and cannot silently override it.
• [ ] Shared-identity migration separates parity from trimming and finishes by proving the old path is denied.
• [ ] Operators can trace claim revision, admission decision, composition revision, provider request, cloud state, runtime token, and probe.
• [ ] Capability owners, versioning, deprecation, exceptions, service-level objectives, and support responsibilities are documented.