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