Workload Identity Capability

Purpose: Define how services authenticate to GCP without static keys.

Why this capability exists

Workload Identity is described in both manifests and infrastructure docs. This page becomes the canonical contract and decision point.

Capability contract

Platform is responsible for:

• Creating and managing GSAs and IAM roles
• Creating KSA to GSA bindings
• Publishing naming and permission standards

Application teams are responsible for:

• Using the correct KSA in workload specs
• Requesting least-privilege access only
• Validating runtime access with explicit checks

Implementation flow

1. Define required GCP permissions by use case
2. Create or reuse target GSA
3. Bind KSA to GSA
4. Annotate workload to use KSA
5. Verify token exchange and real API access

Source starting points

• iot-manifests/docs/concepts/workload-identity.md
• iot-manifests/docs/reference/security.md
• iot-infrastructure/docs/concepts/iam-and-workload-identity.md
• iot-infrastructure/docs/reference/infrastructure/service-accounts.md

Definition of done checklist

• [ ] No static service account key file in repo or image
• [ ] KSA to GSA mapping documented
• [ ] IAM roles scoped to least privilege
• [ ] Verification commands documented
• [ ] Failure modes documented (403, missing annotation, missing binding)