RFC-WORKLOAD-IDENTITY-0001                                      Section 2
Category: Standards Track                                    Requirements

2. Requirements

← Previous: Introduction | Index | Next: Architecture →

2.1 Design Goals

2.1.1 Primary Goals

2.1.2 Secondary Goals

2.2 Non-Goals

These are explicitly out of scope for this RFC:

2.3 Architectural Invariants

Invariants are rules that MUST always be true. Violation of an invariant indicates an architectural breach.

Identity Authority (INV-1 to INV-3)

INV-1: Workload Identity Authority

Every workload MUST have a cryptographically verifiable identity issued by an authorized identity provider (SPIRE, Kubernetes, or cloud provider).

Rationale: Anonymous or unverifiable workloads cannot be trusted. Cryptographic identity enables mutual authentication and audit.

Enforcement: Service mesh rejects connections without valid identity; Vault denies requests from unidentified workloads.

INV-2: No Long-Lived Credentials

Workloads MUST NOT use long-lived static credentials (API keys, service account keys, passwords). All credentials MUST be short-lived and automatically rotated.

Rationale: Long-lived credentials create extended windows for compromise. Short-lived credentials limit blast radius.

Enforcement: Vault policies enforce max TTL; SPIRE agent rotates SVIDs; no static secrets in Kubernetes Secrets (except ESO-managed).

Exceptions: Bootstrap credentials (e.g., SPIRE join tokens) may have longer TTL but MUST be single-use.

INV-3: Identity Attestation

Workload identity MUST be based on attestation of workload properties (Kubernetes metadata, cloud instance metadata, binary signatures) rather than pre-shared secrets.

Rationale: Pre-shared secrets can be stolen and used from anywhere. Attestation proves the workload is what it claims to be.

Enforcement: SPIRE requires attestation for SVID issuance; cloud providers require instance metadata for STS.

Authentication (INV-4 to INV-6)

INV-4: Kubernetes Auth for Vault

Kubernetes workloads accessing Vault MUST authenticate using the Kubernetes auth method with projected service account tokens.

Rationale: Kubernetes auth eliminates "secret zero"—the workload's Kubernetes identity serves as the initial authentication.

Enforcement: Vault Kubernetes auth method validates token with Kubernetes API; legacy tokens rejected.

INV-5: OIDC Federation for CI/CD

CI/CD pipelines accessing cloud resources MUST use OIDC federation (GitHub Actions OIDC, GitLab CI OIDC) rather than static credentials.

Rationale: Static credentials in CI/CD systems are a major attack vector. OIDC tokens are short-lived and bound to the pipeline run.

Enforcement: Cloud IAM policies require OIDC claims (repository, workflow, branch); static credentials removed from CI/CD.

INV-6: mTLS for Service Communication

Service-to-service communication MUST use mutual TLS with certificates bound to workload identity.

Rationale: mTLS ensures both parties are authenticated and traffic is encrypted.

Enforcement: Service mesh denies plaintext connections; network policies restrict non-mesh traffic.

Authorization (INV-7 to INV-9)

INV-7: Namespace-Scoped Permissions

Workload permissions MUST be scoped to the minimum required namespaces and resources.

Rationale: Broad permissions violate least privilege. Namespace scoping limits blast radius of compromise.

Enforcement: Policy templates use identity metadata; ClusterRoleBindings require justification.

INV-8: Delegation Chain Preservation

When workloads act on behalf of other principals (human or machine), the delegation chain MUST be preserved and auditable.

Rationale: Without delegation tracking, accountability is lost. "Who authorized this action?" must be answerable.

Enforcement: Token Exchange enforces chain preservation; audit logs capture full delegation context.

INV-9: Authorization Ceiling

Workload permissions MUST NOT exceed the permissions of the identity that created or authorized the workload.

Rationale: Privilege escalation through automation must be prevented.

Enforcement: Token Exchange validates requested scope against delegator's scope; Kubernetes admission validates RBAC grants.

Audit (INV-10 to INV-12)

INV-10: Identity Audit Trail

All identity issuance, authentication, and authorization events MUST be logged with full context.

Rationale: Security investigations require complete identity event history.

Enforcement: SPIRE, Vault, and cloud providers log to centralized system; logs immutable and retained per policy.

INV-11: Delegation Audit

All delegation relationships (human→agent, agent→sub-agent) MUST be logged with creation, usage, and revocation events.

Rationale: AI agents acting on human behalf must have full accountability.

Enforcement: OAuth 2.0 Token Exchange logs all exchanges; applications log delegation usage with correlation IDs.

INV-12: Cross-System Correlation

Audit logs MUST include correlation IDs enabling tracing across Kubernetes, Vault, SPIRE, and application logs.

Rationale: Distributed systems require correlated logs for incident investigation.

Enforcement: All systems configured to accept and propagate correlation IDs; centralized log aggregation correlates by ID.

2.4 Success Criteria

2.4.1 Identity Coverage

2.4.2 Security Posture

2.4.3 Operational Health

2.5 Invariant Summary

Document Navigation

End of Section 2