generated from coulomb/repo-seed
78 lines
2.4 KiB
Markdown
78 lines
2.4 KiB
Markdown
# Pattern: Break-Glass Access
|
|
|
|
Status: reviewed
|
|
Readiness target: RL3 production
|
|
Primary owners: NetKingdom, Railiance platform
|
|
|
|
## Problem
|
|
|
|
Operators need a recovery path when normal identity, policy, cluster, or
|
|
secret services fail, but emergency access can easily become an
|
|
unbounded platform-root bypass.
|
|
|
|
## Context
|
|
|
|
Use this pattern for OpenBao recovery, cluster recovery, privileged
|
|
account recovery, incident containment, and platform restore workflows.
|
|
|
|
## Forces
|
|
|
|
- Emergency access must work during partial outages.
|
|
- It must be limited, auditable, and rarely used.
|
|
- Tenant administrators must not receive platform-root powers.
|
|
- Post-event review must turn emergency use into durable fixes.
|
|
|
|
## Solution
|
|
|
|
Define a small emergency path with explicit custody, MFA or quorum where
|
|
possible, narrow scope, recorded use, and mandatory post-event review.
|
|
Keep it separate from ordinary administration.
|
|
|
|
## Implementation Sketch
|
|
|
|
1. Identify emergency scenarios and required minimum authority.
|
|
2. Store emergency material separately with named custodians.
|
|
3. Require ceremony, reason, and timestamp for use.
|
|
4. Alert on activation where systems are available.
|
|
5. Rotate or reseal affected credentials after use.
|
|
6. Run post-event review and close follow-up tasks.
|
|
|
|
## Failure Modes
|
|
|
|
| Failure | Mitigation |
|
|
| --- | --- |
|
|
| Break-glass becomes routine admin | require review and track frequency |
|
|
| Emergency access is too broad | define scenario-specific bundles |
|
|
| Recovery material is stale | run drills and rotation checks |
|
|
| Tenant admins gain platform-root access | hard-separate tenant and platform authority |
|
|
|
|
## Related Capabilities
|
|
|
|
- Incident response and recovery.
|
|
- Privileged access management.
|
|
- Secrets, keys, and credentials.
|
|
- Security governance and production readiness.
|
|
|
|
## Maturity
|
|
|
|
Reviewed. The concept is anchored in NetKingdom/OpenBao planning, but
|
|
drills and custody evidence are required before canonical graduation.
|
|
|
|
## Verification
|
|
|
|
- Emergency path is documented and tested.
|
|
- Activation produces an event record and follow-up review.
|
|
- Credentials are rotated or revalidated after use.
|
|
- Tenant and platform emergency powers are separated.
|
|
|
|
## Research Basis
|
|
|
|
Seeded by break-glass access, incident response process, backup restore,
|
|
and secret-zero avoidance requirements.
|
|
|
|
## References
|
|
|
|
- Initial exploration: Identity and access patterns.
|
|
- Initial exploration: Incident response and recovery.
|
|
- Railiance OpenBao platform secrets service.
|