Secret Management Concepts

Copies rest wherever a person once moved the value by hand: a configuration repository and its history, a chat thread, a ticket attachment, a runbook page, a laptop's shell history and terminal scrollback, and private notes.

If disclosing a value lets someone act with rights you hold, it is a secret; if it only tells the process where to go or how to behave, it is configuration. Being sensitive is not the test.

Withdrawing a fleet-shared credential stops every holder at once, not just the compromised host: several hundred collectors fail together. Sharing traded per-host containment for one estate-wide switch, so containment and outage became the same action.

Shortening validity caps how long an undetected leak stays usable: a copy of a one-hour credential found in a log next week is inert, while the four-year one still works. It changes nothing about the minutes an attacker already had.

A usable row names the credential, the system it authenticates to, its class, where the value of record is held, a single accountable owner by name, when it last changed, and the copies known to rest outside the store.

Four things the file structurally cannot: rights granted per name instead of one key that opens everything, a record of each read, withdrawal of one holder without re-keying the rest, and values minted per consumer on request.

Encrypting a store's files removes the value of any offline copy: a stolen disk, a decommissioned volume, a copied backup. It changes nothing for anyone the store answers - an allowed caller, or an operator reading the serving process.

The protecting key must arrive from outside the store's own records: recombined from a threshold of shares held separately, unwrapped by a device or a separate key service the store authenticates to, or held by a managed provider that applies it for you.

Most stores append a version rather than overwriting the old one, so the earlier value stays in the name's history and any caller with read rights on that name can ask for it by version. Replacing is not retiring.

Re-key and replace everything. One file-wide key means the departure exposes every entry, so each value is replaced, the file re-encrypted under a new key and every consumer redeployed. A store withdraws that one identity's grant instead.

Something the store already accepts must be on the machine before it can fetch anything: the bootstrap credential. Moving secrets into a store does not remove that first one. It only decides where it comes from and how long it lives.

A person is present, can answer a prompt, and acts under a name the organisation already knows. A service authenticates with nobody watching, at any hour, so nothing in its path may wait for a human, and its name belongs to no individual.

Forty scattered values became one inventoried set that can be scoped, replaced and recorded centrally. What did not improve is the machine itself: it still holds one static long-lived value, and that value now reaches everything the store will release to it.

A valid signature establishes only that a particular issuer vouched for a particular subject. Whether that issuer is trusted here, which of its subjects are accepted, and which local identity results are all the store's own decisions.

Four things: that the signature comes from an issuer it already trusts, that the document names this store as its recipient, that its subject is a workload the store has a rule for, and that it was minted recently.

Read returns one named value, write creates or replaces a value, and list returns the names under a branch without their contents. Store-wide read-only is still too much because one compromised caller then reaches every credential the estate holds.

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.

Nothing pushes an expiry to a holder. The job copied the value into memory once and never asked again, and validity is decided by whoever accepts the credential — so the expiry surfaces only as a refusal on the next request that presents it.

Each issued credential carries its own lifetime, independent of the session that requested it. Twenty minutes of issuance at a few hundred calls a minute can leave thousands of working credentials that stay valid for their full lifetime afterwards.

A maximum life: a ceiling measured from first issue that no renewal passes. Once it is reached the store refuses to extend, and the only way forward is a different credential, freshly issued and adopted by the consumer.

Renewal moves one field: the expiry. The value, the downstream account behind it and every connection using it stay as they are. Re-issuance mints a different credential, so every holder must be handed the new value and the old one withdrawn.

The downstream system must let the store create a principal on demand, attach exactly that consumer's rights to it, and remove it again — and must accept an identity for the store privileged enough to do all three.

Disabling an account closes one path to the value; it does not withdraw the value. A shared credential the person already read is a copy nobody can recall, so it must be replaced and the old value refused.

A grant list names who may read the value; rotation needs who actually holds it. Permissions overstate it with idle standing grants and understate it with copies taken once, fleets behind one identity, and holders that never call the store.

A one-step swap has no instant at which every holder switches. The database stopped accepting the old password while running processes still held it, so their next connection failed. Safe replacement needs both values accepted at once.

What you can prove decides it, not what is likely. Unless you can establish that every copy on the device was unreadable to whoever now has it, treat the credential as exposed and replace it, then refuse the old value.

Writing a new value into the store is only half a replacement. The system that honours the credential was never told to stop accepting the old value, and every holder still presents it. Withdrawal is a separate action against a different system.

Minting a new key version protects only data encrypted after the change. Anything the leaked version already encrypted stays readable to whoever holds it, along with any ciphertext copy they took, so rotation bounds future exposure and never past exposure.

Key selection, key version, algorithm and rotation all move to the service. The worker still chooses which fields to protect and which logical key name they use, but it keeps ciphertext it cannot read on its own.

Nothing in the objects changed. Rotation rewrites each small wrapped data key under the new wrapping key and leaves every object's ciphertext and every data key exactly as they were, so any copy of a data key or of a ciphertext taken earlier still decrypts.

Only the request and its result cross. The service authenticates, sends a handle naming the key and the instruction's digest, and the device computes the signature internally and returns it. Key material never travels; the operation travels to the key.

A key register records, per key: one owning team, what the key is for, the systems and data it protects, when it entered service, its current state, and which identities may use it.

Any local account that can list processes, because the argument list is host-visible bookkeeping rather than private process memory. Copies also survive the run, in whatever records program executions and in the job definition that issued the line.

Commit the template, the rendering step and the identity of the value — its name in the store and the version delivered — and render the value on the host at deploy time. Reproducing a release needs the inputs, not the secret itself.

The file persists. It is readable by anything on the host with file access, it outlives the process and usually the release that wrote it, it is captured by host images and backups, and after a rotation it still holds the previous value.

A held copy takes the secret store off the hot path: one fetch serves thousands of calls, so store latency, its request budget and its brief failures stop landing on live traffic. The price paid is staleness.

A restart, unless something inside the worker re-resolves the value and rebuilds every client constructed from it. Writing a new value into the store changes nothing inside a process that already holds a copy, and the old value must stay accepted until the last holder has moved.

Nothing about the credential changed. The deleting commit edits one file at the tip of one branch. The value still authenticates, still sits in copies taken over six weeks, and is still held by anyone who read it.

One snapshot of one branch was searched. Every other branch and tag, every earlier version of every file on all of them, and every copy living outside that repository — forks, clones, mirrors, exported archives — were never read.

A stolen credential authenticates successfully, so failure-based alerting never sees it. The evidence lives in reads that were permitted — an unfamiliar caller, an odd source or hour, more names or more volume than the job needs.

A history rewrite reaches only the repository you rewrote. Clones, forks, mirrors, the hosting platform's cached view, build logs, published artefacts and every backup taken in those six weeks still hold the value - as does anyone who read it.

Treat the whole interval as unobserved use: assume the credential was copied by strangers throughout it, and scope the response to every right it carried for three weeks, not to the moment you found it.