Blast radius: what one credential unlocks

Blast radius is a measurement, not an adjective. It is the set of actions an attacker can take, over the set of systems they can reach, for the length of time the credential remains usable, reduced by the fraction of that activity you would actually notice. Teams that describe a credential as low risk have usually measured one of those four and guessed the rest.

What a blast radius is made of

Scope is which operations on which objects. Read against write is the obvious split; the less obvious one is whether the identity can act on the authorisation system itself, which turns a bounded scope into an unbounded one in a single call.

Reach is where the credential works from. A database password that only functions from inside one subnet has a smaller radius than the identical password accepted from any address, and the difference costs nothing to configure. Reach is the dimension most improved by network position and least improved by making the secret longer.

Duration is the interval between theft and uselessness. It is the only dimension you set directly with a number, which is why it absorbs the risk whenever the others cannot be tightened.

Detectability is whether malicious use is distinguishable from legitimate use. A credential shared by twenty replicas and used continuously has almost none: every request looks like the others. A credential used by exactly one job at 02:15 each night has excellent detectability, because a call at 14:00 from an unfamiliar address is visibly wrong.

Two credentials make the arithmetic concrete. A token permitting one read on one secret path, valid twenty minutes, accepted only from the cluster network, used by one service on a predictable schedule, gives an attacker one value and a short window in a place they must already be. A cloud access key with an administrative policy, no expiry, accepted from anywhere, and shared by every pipeline gives them the account. Both are “a secret in a store”. They differ by several orders of magnitude.

Transitive authority is the dimension teams miss

Authorisation is drawn as a list and behaves as a graph. What a credential grants directly is only the first hop; what matters is the closure over the edges that lead from one credential to another.

flowchart LR
    A["CI job credential"] --> B["Push to artefact\nregistry"]
    B --> C["Cluster pulls\nthe image"]
    C --> D["Workload runs\nwith its own identity"]
    D --> E["Reads secret\nstore path"]
    E --> F["Cloud credential\nstored at that path"]
    F --> G["Account wide\nAPI access"]

Every arrow in that chain is a legitimate, documented permission. Nobody granted the CI job access to the cloud account, and yet the closure delivers it, because the ability to change what runs is the ability to become what runs. Five edge types account for most of these chains:

• Credential-to-credential. An identity that can read a path in the secret store holds whatever is stored at that path, including other identities.
• Policy edges. An identity permitted to modify policy can grant itself anything, so its scope is by definition every scope the system supports.
• Issuance edges. An identity that can create tokens, sign certificates or add trusted keys can manufacture principals rather than borrow one.
• Supply-chain edges. Write access to a repository, a chart or a registry becomes execution wherever that artefact is deployed, on the deployment system schedule rather than the attacker one.
• Host and platform edges. An identity that can execute inside a container, attach to a process or read a node volume inherits every credential present on that node.

The review technique follows directly. For each credential, ask which other credentials it can obtain, then repeat on the results until nothing new appears. Most estates discover the closure is far larger than the direct grants within two hops, and the answer is usually surprising to whoever wrote the policy.

Narrowing scope: what a least-privilege policy actually denies

Scope reduction is the lever with the best ratio of effort to effect, and it is best learned by watching a narrow policy refuse things. This grants one capability on one path.

path "kv/data/app/config" {
  capabilities = ["read"]
}

A token carrying only that policy can read the configuration secret and nothing else. Reading a sibling path fails. Writing to the very path it can read fails. And listing the directory that contains it fails as well.

Code: 403. Errors:

* permission denied

The listing denial is the interesting one, because the reason is structural rather than arbitrary. A version 2 key-value store splits its API into a data path and a metadata path, so the secret lives at kv/data/app/config while enumeration is an operation on kv/metadata/app. A rule about the data path therefore says nothing at all about listing, and the failure arrives at the least convenient moment, usually during a deployment, presenting as a permission problem that looks like a mistake in the rule that was just written.

Shortening life and reducing copies

Duration is set by a number, so it is the lever available even when scope cannot be reduced further. A dynamic database credential issued with a two-minute lease gives an attacker two minutes; the same access granted as a static password gives them until somebody notices. Where the platform can issue on demand, the useful question is not whether the lease is short enough for comfort but whether the application renews correctly, because a short lease with broken renewal is an outage waiting for a quiet weekend.

Copies are the dimension nobody budgets for. Each location a value rests in is an independent compromise path, and the count is the honest exposure figure: a value in the secret store, in a build artefact, in an environment variable, in a log line and on a laptop has five paths, not one. Fetching at run time instead of baking at build time removes one. Not writing to disk removes another. Passing the value through a file descriptor or a protected file rather than a command-line argument removes a third, because process arguments are readable by other users on the host.

Binding narrows reach without touching scope. Scope a token to a single audience so it is refused elsewhere. Restrict source addresses where the network topology is stable. For pipeline identity, pin the trust policy on both the audience and the subject, and add the environment or workflow reference where the platform exposes it: a policy pinned only to the repository will happily accept any branch and any workflow in that repository, including one added by whoever opened the last pull request.

The availability blast radius of the credential system

There is a second meaning of blast radius that reviews rarely cover: what breaks when the issuer is unavailable rather than when the credential is stolen. A secret manager is a dependency of every workload that fetches from it, and its failure mode is not subtle.

Code: 503. Errors:

* Vault is sealed

While the store is sealed, nothing can read a secret and nothing holding a renewable lease can renew it, so the estate degrades in two waves: new starts fail immediately, and running workloads fail as their leases expire. The design questions follow from that shape. Does the workload cache the value it fetched, and for how long? Does it fail closed at start-up or continue serving on what it already holds? Does the unsealing procedure depend on anything stored inside the system it unseals? Answering the last one honestly has saved more outages than any policy review.

Production discipline

1. Record all four dimensions when a credential is created. Scope, reach, duration and detectability in four short lines is enough, and it makes the next review a comparison rather than an investigation.
2. Compute the closure, not the grant. Follow every edge from a credential to the credentials it can obtain, and keep going until the set stops growing.
3. Separate reading secrets from changing policy. An identity that can do both has no meaningful scope at all, whatever its rules currently say.
4. Never widen a path to resolve a permission error. Fix the specific missing capability or remove the need for it, and treat a wildcard in a policy diff as a change requiring the same scrutiny as a firewall rule.
5. Review the unavailability case alongside the theft case. Write down what fails at start-up, what keeps serving, and how long the estate survives without the issuer.

Cross-course references

• Kubernetes for Production Sysadmins - Part LVIII (RBAC) covers the cluster authorisation model where the same closure problem appears, particularly around identities permitted to create workloads.
• Git, CI/CD & GitOps for Infrastructure Engineers - Part XCI (LeastPrivilege) covers scoping pipeline permissions, which is the supply-chain edge in the diagram above.
• Linux for Production Sysadmins - Part V (Sudo) covers the host-level version of the same reasoning, where one permissive rule quietly grants a path to full root.

Quiz