Policy & Least Privilege

Break-glass access is pre-authorized but held by nobody day to day: it is opened deliberately, bounded by a time box, alerts a channel the opener cannot suppress, and is reviewed after every single use.

Reviewed text gives a rule change a proposal, an approver and a declared set the live rules can be compared against. A live edit gives none of those, so an undeclared grant has nothing to show up against.

Write the four observed names in explicitly, but treat the record as a lower bound on need rather than a full picture: extend the observation past the slowest cycle the tool takes part in, and keep a fast way back, before enforcing.

A just-in-time grant replaces an always-live right with one that exists only inside an approved window, so every read carries a reason, an approver and an end time, and nothing is left for anyone to revoke.

The inventory has leaked: which credentials exist, and therefore which partners, projects, environments and downstream systems the estate has. Denying read protects the values, not the names, and names are rarely changed, so the disclosure does not expire.

Running the service and reading its contents are separate rights. Restart, replication, backup, upgrade and health checks all complete against the store's own ciphertext, so an operator identity gets those service-level rights and no read over any stored value.

Write and read are separate rights over the same value. A deploy job generates the new password, so it never needs to learn an existing one; granting only write means a stolen deploy identity can disrupt but cannot collect what the store already holds.

A post-use review must produce a record of who opened the route, when and why, which values were actually read, whether each has since been replaced, and a sign-off by somebody who did not open it.

A rehearsal has to prove the route opens while the failing system is unavailable: the identity used to open it, the place the emergency value is held, the alert path and the operator's own access must not depend on what is down.

It depends on the applier's design. One that converges on the declared set removes the hand edit silently, at an unrelated moment. One that only creates and updates what the file names keeps it forever, unreviewed.

Through a path that does not run through the rules, since the rules now deny you. Designs differ: a credential established at setup and held offline, a quorum of holders, or a rule the applied set may not alter.

The review checked wording, not effect. Access rules are evaluated as a whole set, the subject named is usually a role whose members live elsewhere, and a name pattern matches more than it reads. Only a computed before-and-after tells you who gained what.

Decide from the access record, not from memory. If that identity has read nothing across a full business cycle, remove it — reversibly and announced, with the rule kept verbatim so restoring it takes minutes rather than an outage.

A second approver buys judgment, a reference to an existing work item buys evidence, and a quorum removes the assumption that any single approver is honest and awake. They are not substitutes, and each fails differently.

Because a revoke step is a task that fails silently: nothing breaks when a grant outlives its work, so it is skipped and accumulates. An end time makes continuation, not removal, the action somebody has to take.

The rule matched characters rather than whole name segments, so a pattern written for teams/search also covered teams/search-internal and teams/searchtest. Anchoring the pattern on the separator, and stating how deep it reaches, is what turns a prefix into a boundary.

Rules hold the boundary, not the naming convention. It holds only when no identity's rules span both branches, list is refused at the shared root, write across the boundary is treated as seriously as read, and any shared branch is counted as belonging to everyone who can reach it.

A decision per grant, a named accountable owner who is not the holder, the evidence it rested on, and a default that removes on silence. A review where doing nothing keeps everything removes nothing.

Gate the reads that a person performs rarely against material with a large blast radius. Everything unattended or frequent is controlled by narrow scope and per-consumer credentials instead, because a human in that path is an availability incident waiting for a schedule.

Only that all four could have, at any time. A complete record still shows which reads happened, but with one unlimited role nobody can be ruled out — and if that role can also change the rules, its holders could have granted themselves the read quietly.

Fencing removes the worst outcomes from a grant's reach without anyone knowing what the grant is used for — and it fails open: a name created on that branch tomorrow matches the allow and no deny, so it is readable.

By itself, very little: most requests really are legitimate. Paired with a two-second median response it means nobody is reading them, and the usual cause is that the gate sits in front of routine work rather than exceptional access.

Remove the reasons the write reads. Store each credential as its own whole value so a write replaces rather than merges, compare versions instead of contents, check existence through metadata, and let the consumer confirm by use — then the job needs write and version metadata only.

Standing broad rights are usually justified by the emergency nobody could otherwise handle; a rehearsed emergency route removes that justification, letting everyday grants match everyday work - provided opening it is fast and blameless enough that nobody keeps a private copy.

Not by narrowing its rights, since changing every rule is its job. You move the authority onto things that are reviewable — one protected input, a guarded job definition — split it across several appliers by branch of names, and accept the availability each guard costs.

Name-tree rules make the boundary visible and let a new value inherit a scope automatically, but encode only one hierarchy and turn a rename into a permission change. Label rules express cross-cutting scopes at the cost of depending on data a writer sets.