generated from coulomb/repo-seed
82 lines
2.6 KiB
Markdown
82 lines
2.6 KiB
Markdown
# Pattern: Secret Zero Avoidance
|
|
|
|
Status: reviewed
|
|
Readiness target: RL3 production
|
|
Primary owners: NetKingdom, Railiance platform
|
|
|
|
## Problem
|
|
|
|
A secret manager cannot safely improve the platform if its bootstrap
|
|
material becomes a larger unmanaged secret than the credentials it is
|
|
meant to protect.
|
|
|
|
## Context
|
|
|
|
Use this pattern when introducing OpenBao, encrypted Git secrets,
|
|
emergency bundles, age/SOPS bootstrap material, or recovery ceremonies.
|
|
|
|
## Forces
|
|
|
|
- The platform needs an initial trust anchor.
|
|
- Operators need recoverability, but ordinary workloads must never use
|
|
platform-root material.
|
|
- GitOps needs reproducible configuration, but secret plaintext does not
|
|
belong in repositories.
|
|
- Emergency access must exist without becoming normal operating access.
|
|
|
|
## Solution
|
|
|
|
Separate bootstrap trust from runtime secret authority. Use encrypted
|
|
bootstrap material only for installation and recovery, then transfer
|
|
ordinary secret issuance, rotation, audit, and lease tracking to
|
|
OpenBao.
|
|
|
|
## Implementation Sketch
|
|
|
|
1. Store bootstrap and recovery material in encrypted form with explicit
|
|
custody.
|
|
2. Require a documented ceremony for unseal, restore, and emergency
|
|
recovery.
|
|
3. Move runtime workloads to OpenBao-issued or brokered secrets.
|
|
4. Keep root/recovery material out of normal deployment paths.
|
|
5. Record every break-glass or bootstrap use as a review event.
|
|
|
|
## Failure Modes
|
|
|
|
| Failure | Mitigation |
|
|
| --- | --- |
|
|
| Bootstrap root token reused by workloads | prohibit root material in runtime manifests |
|
|
| Encrypted secret repository becomes undocumented | maintain owner, recipient, and rotation inventory |
|
|
| Recovery ceremony untested | run restore and unseal drills |
|
|
| Emergency bundle becomes daily admin path | require post-event review and replacement |
|
|
|
|
## Related Capabilities
|
|
|
|
- Secrets, keys, and credentials.
|
|
- Security governance and production readiness.
|
|
- Incident response and recovery.
|
|
- Observability, detection, and audit.
|
|
|
|
## Maturity
|
|
|
|
Reviewed. NetKingdom credential and OpenBao architecture already anchor
|
|
the pattern; operational drills are still needed before canonical status.
|
|
|
|
## Verification
|
|
|
|
- Runtime workloads do not reference bootstrap root material.
|
|
- OpenBao audit is enabled before production use.
|
|
- Recovery and unseal steps are documented and tested.
|
|
- Emergency access events produce reviewable records.
|
|
|
|
## Research Basis
|
|
|
|
Seeded by encrypted Git secret, central secrets management, break-glass,
|
|
and incident recovery requirements in the initial exploration.
|
|
|
|
## References
|
|
|
|
- NetKingdom credential-management standard.
|
|
- NetKingdom recursive platform identity/security architecture.
|
|
- Railiance OpenBao platform secrets service.
|