An in-memory tier's one shared credential is held by a workload that has just been compromised — what does that connection reach?
answer
- one credential, one privilege level
- proof of holding, not of being
- no per-key check on most stores
- per-owner rules only where the server has them
basics
~20 sA single server-wide credential proves only that the caller holds a value, not which application it is. Unless the server can express per-owner rules, the accepted connection reaches the whole keyspace: every application's sessions, claims and deduplication records.
solid answer
~50 sThe proof is coarse. On a server that checks one shared credential, presenting it makes the caller *a* caller, not *this* caller, and nothing further is checked per key or per operation — so the compromised workload reads, overwrites and deletes entries belonging to every other application on that instance. Because this tier holds sessions and claims, reading supplies impersonation material, and deleting is both an outage and a correctness problem: leases vanish and two workers do the same job, deduplication records vanish and a retried request runs twice. Some servers do offer per-owner credential rules that tie an identity to key patterns and operation classes, and some have no identity step at all — so the first move is to establish which of the three you are on. Where the server cannot express scope, the only thing bounding that connection is what was allowed to reach the address.
go deeper
A password on this kind of store is usually one value for the whole server, so anyone holding it can use every key on that instance, not only the keys their own application wrote.
Explain that the credential answers "do you hold the value" and nothing more, and that a key prefix is a naming convention the server does not enforce, so it cannot keep a credential holder out of anything.
Price the accepted connection against the contents: reading sessions and claims supplies impersonation, deleting leases creates a second holder, and deleting deduplication records makes a retried request run twice.
Decide what scope you require before a tier is allowed to hold non-replaceable state at all — per-owner rules where the server has them, and a boundary outside the process where it does not, since a feature only some stores have cannot carry a standard.
## What the credential actually proves A credential check on this kind of server answers one question: *do you hold the value?* It does not answer *who are you*, and on a server with a single shared credential it cannot, because every caller presents the same value. That is a different model from the one most engineers carry over from a relational engine, where a login is an identity and rights are attached to it per object. The practical consequence is that **authentication and authorization are the same event here**, and it is coarse. Once the connection is accepted there is, on many servers in this class, no second check at all — no per-key check, no per-prefix check, and frequently no separation between ordinary operations and destructive ones. ## The scope one accepted connection gets On a store with one shared credential and no finer rules, the compromised workload has, on that instance: - **Read of the entire keyspace** — not the subset its own application wrote. It can enumerate keys with a bounded incremental cursor traversal and read whatever it finds. - **Write of any key** — including keys another application will read back and trust. - **Deletion of any key**, and on most stores the ability to empty the instance outright. - On some stores, **settings changes at runtime or a request that the server write a copy to disk**, which turns a data exposure into a host exposure. ## Why a per-team prefix does not help here A prefix convention is a naming scheme. Unless the server's per-owner rules reference it, the server does not interpret a prefix at all — to a connection holding the credential, another team's prefix is simply more keys it may list, read and delete. Prefixes are how you find out *whose* entries something is; they are not a thing anyone has to obey. ## Where per-owner rules change the picture | The server offers | What a stolen credential reaches | What you can still not assume | |---|---|---| | No identity step | Everything reachable on the address | Nothing in-process bounds it; only the network does | | One shared credential | The whole keyspace, every operation | That any application is isolated from any other | | Per-owner credential rules | Whatever that identity's rules allow | That the rules can exclude every destructive or settings-changing operation — what they can express varies | The last column is the part candidates skip. Where per-owner rules exist, their expressiveness differs: restricting key patterns is common, and cleanly separating read from write, and administrative operations from both, is not universal. Confirm what the rules can actually exclude before you tell anyone the identity is bounded. ## What the loss is, given what this tier holds The contents decide the severity, which is why the question is worth asking about *this* tier rather than in general: 1. **Sessions and claims** — reading them gives an attacker material that the application treats as already-proven, so the exposure is an identity exposure, not just a data one. 2. **Leases and locks** — deleting one does not just lose data, it creates a second holder, so two workers perform the same side effect. 3. **Deduplication records** — deleting them makes a retried request look new, so an operation that was supposed to happen once happens again. 4. **A replaceable copy of rows** — the smallest case, but not zero: entries written by the attacker are still believed, and emptying the instance still hands the origin the full load at once. ## What to do with the connection you cannot scope The honest answer for a store that cannot express scope is that the bound has to come from outside the process: - **What could reach the address at all**, which is why placement and deny-by-default routing carry the weight on this class of store. - **A terminating proxy in front of the server** where an identity step is required and the server has none, so the thing being trusted is a component that can express identity. - **What the tier is allowed to hold**, which is the one lever that changes the severity rather than the likelihood. And the diagnostic habit: when someone says "the tier is authenticated", ask which of the three models they are on and what that model can exclude. "It has a password" is a statement about the connection, not about the blast radius.
- What do per-owner credential rules actually bound, where a server offers them?They tie an identity to the key patterns it may touch and the operation classes it may use, so a stolen identity reaches its own prefix rather than the instance. What the rules can express varies by store, so confirm whether they can exclude destructive and settings-changing operations, not merely restrict key patterns — a rule that scopes keys but leaves an instance-wide operation reachable has not bounded much.
- Why is a per-team key prefix not a boundary against a credential holder?Because the server does not interpret a prefix unless per-owner rules reference it. To a connection that has been accepted, another team's prefix is just more keys it may list, read and delete. A prefix answers who owns an entry, which is an accounting fact; it does not stop anyone from touching it.
- The tier holds only a replaceable copy of database rows — does any of this change?The confidentiality loss shrinks; the integrity and availability loss does not. The connection can still write entries the application will trust on the next read, and emptying the instance still puts the origin under the full read load at once. What changes is that you are no longer facing an identity incident, so recovery is a warm-up rather than a revocation exercise.
saying these in an interview costs you the question
- Assumes a credential implies per-key authorization on the server.
- Says a per-team key prefix keeps a credential holder out of other prefixes.
- Treats reading as the whole loss, ignoring deleted leases and dedupe records.
- Assumes every server in this class can express per-owner rules.
- Believes an application can only see the keys it wrote itself.