infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-workload-identity.md

Pattern: Workload Identity

Status: draft Readiness target: RL3 production Primary owners: Railiance platform, NetKingdom

Problem

Workloads need to authenticate to platform services without inheriting human credentials, static shared secrets, or tenant-ambiguous service accounts.

Context

Use this pattern for Kubernetes workloads, platform services, agents, and background jobs that need access to OpenBao, object storage, databases, queues, or internal APIs.

Forces

• Workloads need stable identity, but credentials should be short lived.
• Kubernetes service accounts are useful local identity evidence, but consumers need a NetKingdom-level identity contract.
• Tenant context must be explicit for multi-tenant workloads.
• OpenBao can issue or broker secrets, but should trust verified workload identity rather than static bootstrap credentials.

Solution

Bind runtime workload identity to the NetKingdom IAM Profile. Validate the Kubernetes service account, namespace, audience, issuer, tenant, and deployment context, then exchange that evidence for scoped credentials, tokens, or policy decisions.

Implementation Sketch

1. Define workload identity subjects and tenant scope in IAM Profile claims.
2. Use Kubernetes projected service account tokens or equivalent runtime attestation.
3. Map service account, namespace, and deployment labels to protected systems and tenant scope.
4. Let OpenBao Kubernetes auth or a credential broker validate runtime evidence.
5. Issue scoped, short-lived credentials with audit correlation.
6. Deny requests when workload identity and tenant context disagree.

Failure Modes

Failure	Mitigation
Shared namespace account reused across services	require workload-specific service accounts
Tenant missing from identity evidence	fail closed and require explicit tenant binding
Long-lived mounted credentials	use short TTLs and rotation
OpenBao trusts weak Kubernetes metadata	validate issuer, audience, namespace, service account, and bound claims

Related Capabilities

• Identity and user management.
• Secrets, keys, and credentials.
• Tenant isolation.
• Observability, detection, and audit.

Maturity

Draft. The pattern is well aligned with OpenBao and IAM Profile goals, but it needs a concrete Railiance implementation path and verification fixture before graduation.

Verification

• Workload tokens have expected issuer, audience, subject, and tenant.
• OpenBao or broker policy rejects wrong namespace/service account combinations.
• Credentials are short lived and auditable.
• Tenant mismatch tests fail closed.

Research Basis

Seeded by the initial catalogue entries for service identities, workload secret injection, tenant context propagation, and external secrets.

References

• Initial exploration: Identity and user management.
• Initial exploration: Secrets and cryptography patterns.
• Railiance OpenBao platform secrets service.