Add security architecture pattern infospace

infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-dynamic-secrets.md

@@ -0,0 +1,76 @@
+# Pattern: Dynamic Secrets
+
+Status: draft
+Readiness target: RL3 production
+Primary owners: Railiance platform, OpenBao
+
+## Problem
+
+Static service credentials accumulate, drift from ownership, and remain
+useful after compromise.
+
+## Context
+
+Use this pattern for databases, object stores, message brokers, internal
+APIs, and operator workflows where credentials can be issued with a
+lease and revoked after use.
+
+## Forces
+
+- Consumers need credentials on demand.
+- Backends vary in their ability to mint short-lived credentials.
+- Lease and revocation behavior must be observable.
+- Application teams need stable integration contracts even when backend
+  credential mechanisms differ.
+
+## Solution
+
+Use OpenBao or a credential broker to issue scoped credentials with TTL,
+lease metadata, renewal rules, and revocation. Keep parent credentials
+inside the platform secret authority.
+
+## Implementation Sketch
+
+1. Define a protected system and role for each dynamic credential type.
+2. Authenticate the caller with workload or human identity.
+3. Authorize requested scope and TTL through policy.
+4. Generate backend-native credentials or brokered session material.
+5. Record lease id, caller, tenant, backend, and expiry.
+6. Revoke credentials on expiry, deployment teardown, or incident.
+
+## Failure Modes
+
+| Failure | Mitigation |
+| --- | --- |
+| Backend does not support dynamic users | use brokered credentials or shorter static bridge with explicit exception |
+| Lease renewal hides stale consumers | cap max TTL and require owner metadata |
+| Parent credential exposed to apps | keep parent material only in OpenBao or broker config |
+| Revocation is untested | include revocation drills in readiness gates |
+
+## Related Capabilities
+
+- Secrets, keys, and credentials.
+- Authorization and access control.
+- Observability, detection, and audit.
+
+## Maturity
+
+Draft. The OpenBao direction is established, but each backend needs a
+verified lease and revocation story.
+
+## Verification
+
+- Issued credentials have owner, scope, TTL, and lease metadata.
+- Revocation invalidates access at the backend.
+- Expired credentials are rejected.
+- Audit records link issuance and revocation to actor and tenant.
+
+## Research Basis
+
+Seeded by central secrets management, workload secret injection, secret
+rotation, short-lived credentials, and OpenBao runtime authority.
+
+## References
+
+- Initial exploration: Secrets, keys, and credentials.
+- Railiance OpenBao platform secrets service.