What does a secret store give that one encrypted credentials file cannot, when the file's key is held outside the repository?

## What the encrypted file already gets right A credentials file committed to a repository and encrypted, with the key that opens it held somewhere else, genuinely provides one property: **confidentiality at rest**. Anyone who gets a copy of the repository — a clone, an old backup, a laptop that left the building — gets ciphertext. That is not nothing, and it is why the reflex answer ("never commit a credential in plaintext") is not the answer to this question. The interesting part starts once that property is granted. A **secret store** is a running service that holds values and answers requests for them, and the case for paying that operational cost rests on four things the file cannot do however well it is encrypted. ## One key against rights over a branch of names The file has exactly one unit of access: the key that decrypts it. Whoever holds that key reads **every entry**, because decryption is all-or-nothing over the whole file. There is no way to express "this service may read the two values it needs and nothing else", and no way to express "this person may write this entry but never read that one". A store expresses access as a rule over **a branch of the name space**: an identity is granted read on one branch, and the store refuses everything else. The reach of one compromised consumer becomes the set of names it was granted rather than the entire inventory. That is the difference between a blast radius of one file and a blast radius of one grant. ## A read you can see against a read you cannot Decryption of a file happens **on the reader's own machine**, with no participation from anything you operate. Nothing observes it. Afterwards you can reconstruct who held the key and when they last pulled a copy, which is a statement about *opportunity*, not about *use*. When a store serves the value, every successful read is an event the store recorded — which identity, which name, at what time. That record is what turns "assume all forty entries are exposed" into "these three names were fetched". It bounds the scope of the clean-up; it does not prove what the reader did with the value once they had it. ## Withdrawing one holder against re-keying everyone There is no per-holder object in a file, so there is nothing to withdraw. Removing one holder means: replace every value the file held, re-encrypt the file under a new key, distribute that new key to everything that decrypts at deploy time, and redeploy every consumer. The cost scales with entries multiplied by consumers, and it is the same cost for a routine departure as for an emergency — which is precisely why, in practice, it is skipped, and why the departed holder's copy stays good. In a store you revoke that one identity's grant. Every other holder is untouched, and the rotation list narrows to the names that identity could reach. ## Values you hold against values made on request A file contains only what somebody typed into it. That value is long-lived by construction, shared by everyone who reads the file, and identical everywhere it is used, so no use of it is attributable and withdrawing it affects everyone at once. A store that has been given authority on a downstream system can instead **create a credential per consumer at request time**: each consumer gets its own account with its own rights, and no shared password exists for anyone to copy. Store designs genuinely differ here — some mint downstream credentials, others only hold what you gave them — so this is a capability to check for, not one to assume. ## The four gaps side by side | Question | One encrypted file | A secret store | |---|---|---| | Who may read one value? | Anyone holding the file's key reads all of them | A rule grants one identity read over one branch of names | | Who did read it? | Unknowable — decryption is offline | Each read is an event the store recorded | | One holder leaves | Replace every value, re-key the file, redeploy everyone | Withdraw that identity's grant | | Where the value comes from | Only what a person typed in | Can be minted per consumer on request | ## What moving to a store does not give you - It does not write your access rules. A store with one wildcard grant reproduces the file exactly, with better logging: **proving who is calling and deciding what they may read are separate steps**, and the second is still yours. - It does not make the values that were in the file safe. They stay live until each one is replaced; moving a value is not the same as replacing it. - It does not recall copies already delivered to consumers, or the copies those consumers wrote to disk. - It adds a service the whole estate starts against, with its own availability, its own start-up key and its own backups to rehearse. A workable order for the move: 1. Stand the store up and grant each consumer read over only the names it needs. 2. Move each value **and replace it as you move it**, because every value the file held must be treated as known to every key holder. 3. Delete the file and confirm no consumer still reads it before calling the migration done.