Add security architecture pattern infospace

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

@@ -0,0 +1,87 @@
+# 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.