RFC: Service Accounts for Cloud Foundry Workload Identity

[rkoster]

Index

• Summary
• Problem
• Developer experience
  • 1. Create an account and assign it to apps
  • 2. Access a cloud service
    • Team-owned resources
    • Broker-managed services
    • At runtime
  • 3. Let a coding agent use the Cloud Foundry API
  • 4. Authorize app-to-app routes
  • 5. Manage the account
• Identity model
• Lifecycle and security
• Permissions and limits
• Alternatives considered
• Status and next steps
• Appendix: implementation notes
  • A. Open Service Broker API
  • B. Example RDS binding and operator setup
  • C. UAA client registration
  • D. Platform components
  • E. CA rotation

Summary

Propose service accounts: named identities that a team creates in a space and assigns to one or more apps. Apps prove their account with the certificate Cloud Foundry already gives every instance and exchange it for short-lived UAA tokens. No secret is ever handed to the app.

The main use is workload identity federation (WIF) with cloud services, whether owned by the application team or provisioned by a service broker. The same identity also lets coding agents running as CF apps call the Cloud Foundry API, and authorizes app-to-app routes.

One account, multiple apps, no shared secrets, explicit permissions.

Why

Platform teams need workload identities that are shared by a chosen set of apps, stable across app replacement and renames, human-readable, known before the platform exists (so external roles can be created in advance, including for disaster recovery), secretless, and explicitly authorized. For the most sensitive data, teams often own their cloud accounts and write trust policies themselves, so a readable, predetermined identity matters. Instance, app, org and space identities each fail at least one of these requirements.

Proposal at a glance

• cf create-service-account payments-worker, then cf bind-service-account APP payments-worker. An app has at most one account; many apps in the owning space can share one. Changes apply on restart.
• The name appears as token subject cf:service-account:payments-worker, certificate SAN payments-worker.svc.identity, and route-policy source cf:svc:payments-worker. Names are immutable, foundation-unique RFC 1123 labels; deleted names stay reserved.
• Team-owned resources: teams write cloud trust policies (e.g. an AWS IAM role) for the issuer and subject, in advance.
• Broker-managed services: cf bind-service is unchanged. Cloud Controller adds the account's issuer and subject to the CF context of the bind request; the broker creates and removes its grant. No new plan capability.
• Tokens are bearer JWTs (at most five minutes, never past the certificate's expiry), without cnf, since cloud WIF does not verify proof of possession; this can be revisited later. Tokens carry instance/app/space/org GUIDs for audit.
• Assigning an account grants nothing. Access comes from external grants, explicit Cloud Controller roles or route policies. Disable stops new tokens; nothing is instant revocation.
• Space Developers create accounts (like service instances); Space Managers disable/delete. Space quotas gain an account limit; operators can set a creation budget against name hoarding. Space/org deletion cascades.

Three Mermaid diagrams cover provisioning, token exchange with AWS STS, and a coding agent calling Cloud Controller. An appendix covers OSBAPI, an example RDS binding, the UAA client registration, platform components and CA rotation.

Existing work

UAA certificate-based client authentication is implemented and agreed with the UAA team, pending final review in UAA #4076, including the opt-in certificate-binding policy, validated in a CF lab.

Companion drafts: Cloud Controller #5520, capi-release #702, BBS #168, Diego #1216, CLI #3875.

Review requested

The next step is community review and RFC approval of the identity model and developer experience. The RFC status remains Draft; no RFC number or FCP is requested yet.

@cloudfoundry/toc — relevant working groups include App Runtime Interfaces, App Runtime Platform and App Runtime Deployments. Feedback is requested from CAPI, Diego/BBS, UAA, CLI, networking and service-broker maintainers.

[Copilot]

Copilot review overview

🟡 Changes recommended

The owning-space deletion contract and safeguards against unbounded global tombstones need definition.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Bound tombstone retention to prevent quota and name-reservation abuse · New
• Define account behavior when the owning space or org is deleted · New

What changed in this PR

Proposes space-owned service accounts for stable, secretless Cloud Foundry workload identities.

Changes:

• Defines account lifecycle, permissions, quotas, and app assignments.
• Specifies UAA JWT federation, broker integration, and CAPI access.
• Extends identity-aware routing for service-account identities.

File	Description
toc/​rfc/​rfc-draft-service-accounts.md	Adds the service-account RFC and developer workflows.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[pbusko]

IMO this feels like a lot of new concepts and lifecycle machinery for what the federation case actually needs, and most of it looks like it's there to manage the new resource rather than solve the original problem.

mTLS auth with SAN matching is already in the UAA, the actual gap is just a stable identifier that a selected set of apps can share.

Instead of a new first-class resource, could that association just be an app label? e.g.

cf set-label app payments-api identity.cloudfoundry.org/service-account=payments-worker

That's the SPIFFE/OIDC workload-identity style, and space-scoping also drops the need for the creation budget. Today UAA matches against a pre-registered SAN, so for this to work it'd need to read the subject straight from the cert instead. And the SAN would have to be space-scoped, so one app can't grab another space's identity.

[rkoster]

@pbusko — responding to your suggestion to use app labels and space-scoped identities:

Instead of a new first-class resource, could that association just be an app label?

I explored SPIFFE-based identity earlier, including an end-to-end UAA/Diego POC and research on name-derived identities. The main question is the canonical identity and its lifecycle, rather than how an app expresses its assignment.

At Rabobank, a recurring requirement—raised repeatedly during the route-policy work—is human-readable, stable identifiers that teams can use directly in external authorization policies.

Those identifiers must also be known before the platform exists. For disaster recovery, we want to pre-create external WIF roles and trust policies, then recreate the platform and push apps using predetermined identities. Requiring each team to create CF resources, retrieve a generated GUID-based identity, provision external roles, and only then deploy introduces sequencing and state-management complexity into every application pipeline.

A space GUID plus an account label could form a valid SPIFFE ID, but would not meet that pre-provisioning requirement and would change when the space is recreated. Using org/space names instead introduces other problems: CF permits names up to 255 characters, including printable punctuation and Unicode, and those names are mutable. SPIFFE path segments permit only letters, digits, dots, dashes and underscores, and prohibit percent-encoding. Lossy sanitization/truncation introduces collisions; name-based paths change on rename. Deterministic hashing can address representation, but sacrifices readability.

The proposed account name is therefore human-readable, immutable and chosen in advance, independently of platform-generated GUIDs. External policies can be prepared for cf:service-account:payments-worker before CF resources exist. Trust remains scoped to the planned UAA issuer; a different recovery issuer must also be pre-authorized.

This does not rule out SPIFFE: the predetermined account name could appear in a URI SAN. The distinction is the identity model, not DNS versus URI encoding.

A label could be an assignment UX, but needs platform-controlled authorization and issuance: ordinary metadata must not let an app claim an identity with existing grants. Explicit CAPI roles, broker grants and disable/delete behavior also need lifecycle semantics independent of any one app. That is why the RFC models the shared identity as a resource.

Today UAA matches against a pre-registered SAN, so for this to work it'd need to read the subject straight from the cert instead.

That changes the authentication profile. RFC 8705 tls_client_auth requires an exact expected DN/SAN registered for each client. Deriving an unregistered client/subject from a trusted certificate needs a separately specified issuance profile. This RFC builds on existing exact-SAN registration.

Space-scoping could avoid foundation-wide name contention, but still needs a predetermined, stable namespace and name-reuse semantics. The creation budget is configurable, including unlimited for internal platforms.

[rkoster]

Pushed fe94f46: a restructure of the RFC based on feedback that it was hard to read, plus several design simplifications from the discussion here and on the UAA PR.

Readability

• Reorganized around the developer workflow: problem and requirements first, then what developers do, then identity, lifecycle and permissions. Implementation detail (OSBAPI, UAA client registration, platform components, CA rotation) moved to an appendix.
• Rules and behavior are now tables instead of dense prose; the revocation caveat appears once.
• The main body is now under 1,900 words; implementation detail lives in the appendix. The document grew slightly overall because of the new requirements, alternatives and team-owned examples.

Clearer motivation

• Explicit requirements: shared, stable, human-readable, known before the platform exists, secretless, explicitly authorized. Predetermined, readable identities let teams create external roles in advance, including for disaster recovery.
• New Alternatives considered section covering app labels, GUID-based (e.g. SPIFFE) identities, org/space-name-derived identities, existing app identity and per-app secrets (following up on the discussion with @pbusko).

Team-owned cloud resources are now the primary path

• For the most sensitive data, shared brokers are often not allowed: following least privilege, databases live in team-owned cloud accounts and teams write trust policies themselves. The RFC now shows the AWS IAM trust policy a team would write, referencing only values known in advance. Brokers are presented as automating the same setup.

Simpler broker integration

• Dropped the proposed --authentication service-account flag. An app has at most one account, so Cloud Controller simply passes it to the broker.
• OSBAPI scope reduced to adding the account's issuer and subject to the CF context of a bind request. No new plan capability or versioned bind_resource object.
• Federation trust and allowed token audiences are operator configuration set up at deploy time; brokers create and remove their own grants. Cloud Controller no longer approves audiences per binding.

Token and UAA details made concrete

• Explains why tokens carry no cnf: cloud WIF (AWS, Azure, Google Cloud) does not verify proof of possession. Can be revisited later via UAA's per-client setting or DPoP.
• Tokens carry instance, app, space and org GUIDs for audit, using UAA's existing claim mappings.
• Added the full UAA client registration example.
• Added CA rotation, with named UAA trust bundles as the preferred approach (proposed on UAA #4076) and a Cloud Controller fallback.

The PR description has been updated to match.