generated from coulomb/repo-seed
88 lines
2.9 KiB
Markdown
88 lines
2.9 KiB
Markdown
# 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.
|