skip to content

A team holds list but not read over a shared branch of secret names — what has already leaked?

level: middleimportance: must knowfreq 50%

answer

  1. metadata is content here
  2. names are written for humans
  3. an inventory, not a value
  4. rotation never changes a name
  5. the target list is already built

basics

~20 s

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.

solid answer

~50 s

Names in a secret store are written by humans to be recognisable, so they carry meaning: `partner-feed-acme-freight` names a commercial relationship, `project-lighthouse-api-key` names something unannounced, and the segments around them reveal how many environments exist and which systems are in the estate. A caller holding `list` and not `read` has all of that. It also has a target list — it knows exactly which names to try if it ever gains read, or which systems to attack directly. The disclosure is durable in a way a value is not: rotating a credential changes the value, nothing about it changes the name, so there is no cheap repair short of renaming and re-pointing every consumer. Grant list over the branch a caller owns, deny it at shared roots, and keep meaning out of names you cannot scope tightly.

code

json · 10 lines
json
{
  "branch": "teams/search/prod",
  "names": [
    "index-writer-db",
    "partner-feed-acme-freight",
    "partner-feed-northwind-logistics",
    "project-lighthouse-api-key"
  ],
  "valuesReturned": false
}

go deeper

for a junior

Remember that list returns names without contents, and that a name written to be recognisable by people is readable by anyone who holds that right.

for a middle

Explain what the names themselves disclose — counterparties, unannounced work, environments, downstream systems — and why denying read does not undo it.

for a senior

Show the durability argument: values can be replaced, names cannot be cheaply, so treat the disclosure as permanent and fix the scope of the grant instead.

for a principal

Weigh operability against disclosure: meaningful names are why the estate is workable, so decide which nouns belong in the name space and which belong elsewhere.

## The name is content A secret store's names exist to be read by people: an engineer has to find the value, an on-call responder has to recognise it at three in the morning. So names get written the way documentation gets written — `teams/payments/prod/partner-feed-acme-freight` rather than an opaque identifier. That readability is exactly what makes a branch listing a disclosure. The right to **list** returns the names under a branch without their contents, and the names alone answer questions an outsider is not supposed to be able to ask. ## What a listing actually hands over - **Commercial relationships.** A name containing a counterparty says you integrate with them, before either side has announced it. - **Unannounced work.** Project code names appear in credential names months before the project appears anywhere else. - **The shape of the estate.** Segments reveal how many environments exist, which regions are live, which teams exist and roughly how big they are. - **The downstream systems.** `ledger-db`, `index-writer-db`, `payout-gateway` name the systems worth attacking, whether or not the credential itself is reachable. - **A target list.** If read is ever gained — a widened rule, a second compromise, a different identity — the holder no longer has to guess names. - **Change over time.** Repeated listings show what was created and removed, which is a rough feed of what the organisation is building and shutting down. | what the name segment says | what a reader infers | |---|---| | a counterparty's name | an integration exists, and with whom | | a project code name | something unannounced is in flight | | an environment segment | how many environments there are, and which are live | | a system name | which downstream systems to go after directly | ## Why *read is denied* is not the mitigation people think Three properties make this worse than the usual metadata leak. 1. **Names are durable.** Replacing a credential changes the value; nothing about that changes the name. The information disclosed stays true indefinitely, and repairing it means renaming the value and re-pointing every consumer that reads it. 2. **The expensive half of an attack is discovery.** Knowing that `partner-feed-acme-freight` exists is most of the work; the rest is finding any identity that may read it. 3. **The leak is quiet.** A denied read is a refusal someone might notice. A permitted list is an ordinary, successful operation that looks like the tool working. ## When list is genuinely needed Enumeration is not a mistake by itself — an inventory job, a reconciliation tool comparing declared consumers against what exists, and a human looking for the value they are about to rotate all need it. The point is to make the grant deliberate: - Grant `list` over the branch the caller owns, not over the root that contains every team. - Where the store has a deny rule, deny list at the shared root so nobody enumerates across the boundary by accident. - Treat a request for list over everything the way you would treat a request for read over everything — as a scope question, not a convenience. ## Designing names so a listing costs less There is a real trade here and no free answer. Names that carry meaning are the reason the estate is operable; names that carry no meaning are unusable at three in the morning and push people to keep a mapping document somewhere less protected than the store. A workable middle: - Keep structural segments (team, environment, system) meaningful — they are the boundary you scope rules on anyway. - Keep the genuinely sensitive nouns out of the name and in the value's description or attributes, which are usually a separate right to read. - Where a counterparty or an unannounced project must be identified, use a stable internal identifier that means nothing outside the organisation, and keep the mapping where the rest of that project's material already lives. ## The answer an interviewer is listening for They want to hear that you do not treat list as a harmless subset of read — that you can say *what* leaked, *why it does not expire*, and *what you would still grant it for*. A candidate who says the values are safe so nothing happened has missed the right's whole reason for existing as a right.

  • If the names have already leaked, is renaming the values worth doing?
    Rarely on its own. Renaming means re-pointing every consumer and leaves the old knowledge true, so it buys little unless the names are still being enumerated. Narrow the list grant, deny list at the shared root, and treat the disclosed facts as disclosed when you decide what else to change.
  • Does encrypting values at rest reduce what a listing discloses?
    No. At-rest encryption protects a stolen disk or a stolen backup; it does nothing about a caller the rule allows. The listing is a permitted operation that the store answers in the clear, so the only control that bites is the scope of the list right itself.
  • Who realistically has list across a shared root without anyone noticing?
    Usually general-purpose tooling — an inventory scanner, a reconciliation job, a dashboard, a deployment helper — plus whatever role new engineers are put in on day one. These grants get written once, cover the root because it was easier, and are never revisited because nothing about them fails.

A locked filing cabinet whose drawer labels are readable from across the room. You cannot open the drawer marked Acquisition - Project Lighthouse, but you now know there is an acquisition, and what it is called.

saying these in an interview costs you the question

  • Says nothing leaked because the values stayed unreadable
  • Treats names as internal details with no sensitivity
  • Claims rotating the values repairs a leaked listing
  • Assumes list is a safe default to hand every caller
  • Thinks at-rest encryption limits what a listing shows