Distributed Lock Service  ·  View 25 of 26  ·  7 · Assurance

Force-Release — Two People, One Reason, One Trail

The only path by which anyone other than the holder can end a hold, and what it records.

Editable source SVG draw.io All views
On-call SRE Keycloak Admin API Second approver Lock log Audit tailer 1. sign in · MFA 2. JWT · role lock-operator 3. force-release key · reason 4. look up class · fenced? 5. warning if advisory 6. approval request 7. approve · different subject 8. Txn: delete holder · put reason 9. committed · revision R 10. delete event R 11. join reason · fenced flag 12. released · next token > R Force-Release — Two People, One Reason, One Trail Force-release is safe only when the class is fenced. The console says so before the second approval, not after. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • The requester and the approver must be different Keycloak subjects, both with the lock-operator role and MFA. The Admin API enforces it; the UI merely reflects it.
  • The reason and both identities are written as a /sys/force record in the same etcd transaction as the delete, and the tailer reads both at one revision. The audit record cannot exist without the release, or the release without the record.
  • The revision of the delete is the floor for the next token. The next grant on that key is strictly higher, exactly as it would be after a normal release.

Stated plainly in the console

  • On an advisory class the old holder may still write successfully after the release, because nothing at the resource refuses it. The console shows this before approval and the record keeps class_was_fenced.

Retention

  • Force-release records: seven years under object lock, driven by audit policy rather than engineering need.
◀  Security — Trust Zones All views Failure Modes  ▶
Solution Architecture v1.0 · Platform Architecture · 2026-09 · 26 views · open source, fully on-premises25-force-release-sequence