How do you calculate blast radius?

You calculate blast radius from permissions, not from behaviour. List everything an identity is allowed to do (in Kubernetes, the verbs and resources in its RBAC bindings), assume every one of those actions is taken at once, and describe what would break. If the identity can exec into a pod or hold a cluster-wide role, the honest answer is usually 'everything in the cluster'.

What is the difference between blast radius and least privilege?

Least privilege is the practice; blast radius is the measurement. Least privilege tells you to grant the minimum access needed for the task. Blast radius tells you how well you did: it is the damage still possible after the grant. You can follow least privilege and still have a large blast radius, because the minimum access a task genuinely requires is sometimes very broad.

Does Kubernetes RBAC limit blast radius?

It can, but only to the extent that the roles are actually narrow. RBAC is expressive enough to permit one verb on one resource in one namespace. In practice most teams bind broad built-in roles because narrow ones are laborious to write and maintain, and a broad role scoped to a namespace still leaves the whole namespace inside the blast radius.

Concepts

Blast radius

Blast radius is the amount of a system that a single action can damage: everything that breaks if one command, one credential, or one person does the worst thing available to them. A developer holding cluster-admin on a production Kubernetes cluster has a blast radius of every service in that cluster, whether or not they ever intend to touch more than one of them. That is the useful property of the term: blast radius is set by the permission, not by the intent behind it, so it can be measured before anything goes wrong. Enumerate what an actor is allowed to do, assume all of it happens at once, and what you are left with is the blast radius.

How to measure it

You cannot measure blast radius by looking at what people did. You measure it by what they could do. In Kubernetes that means reading the RBAC bindings rather than the audit log: a role is a set of verbs over a set of resources, and a binding attaches it to a subject in a namespace or across the whole cluster. The Kubernetes RBAC documentation is the authority on the mechanics; the question to bring to it is not "has anyone deleted a namespace" but "who is currently able to".

It helps to read a permission along three axes, because a grant can be dangerous on any one of them:

Reach. How many things it touches: one deployment, one namespace, or the cluster.
Depth. What it can do to them. get and list are not delete, and exec into a running pod is barely a Kubernetes verb at all: it is a shell, and a shell is every verb the container's filesystem and network can reach.
Duration. How long it exists. A permission that is never revoked has a blast radius that keeps compounding, which is the subject of standing access.

Why it grows on its own

Nobody sets out to give a developer the keys to production. Blast radius grows because every individual step that grows it is the reasonable one at the time.

Broad roles are easier to grant than narrow ones. Writing a role that permits exactly one operation on exactly one workload takes an afternoon and has to be maintained; edit on the namespace takes a minute and always works.
Access granted during an incident outlives the incident. Nothing breaks when a permission is left in place, and something might break if it is removed, so permissions ratchet.
The tools themselves are coarse. kubectl is a client for the whole API, so granting someone the ability to restart a service by giving them kubectl grants them the ability to do everything else the API allows.

That last point is the one worth sitting with. If the only thing a developer actually needs is a rolling restart of one deployment they own, the blast radius of that operation is one deployment. The blast radius of the access required to perform it by hand is the cluster. The gap between the two is risk that nobody chose and nobody is using.

How to shrink it

Narrow the permission. Fewer verbs, fewer resources, one namespace. This is least privilege, and it is the standard advice for a reason.
Shorten its life. A permission that only exists while it is being used has a much smaller blast radius than the same permission left standing.
Replace the access with the action. Do not grant the verbs and hope the operation is performed correctly; provide the operation and never grant the verbs. This closes the gap above rather than narrowing it.
Make the boundary observable. A limit you cannot audit is a limit you are guessing about. Every action should leave a line saying who did what, to what, and when.

The third move is the one most teams skip, because it requires someone to package the operation. It is also the only one that takes the blast radius of a routine task down to the size of the task itself.

How Spellbook relates to this

That gap, between what an operation needs and what performing it by hand requires, is the thing Spellbook is built around. A spell is one named operation with a fixed effect. /revivify performs a correct rolling restart of a workload you own. It cannot restart one you do not own, and it cannot exec into a pod, read a secret, or scale anything, because those verbs were never granted to the person casting it. The operation carries the permission; the human does not.

The honest limit: this bounds the blast radius of the actions someone can take through Spellbook, and says nothing about the ones they can take another way. If your developers also hold cluster credentials, their blast radius is still the cluster. The point of packaging the operation is that it removes the reason to hold them.

You can cast both spells against a simulated cluster in the demo on the homepage, including the refusals. Spellbook runs self-hosted in your own cluster, and is not open yet.

Common questions

How do you calculate blast radius?: You calculate blast radius from permissions, not from behaviour. List everything an identity is allowed to do (in Kubernetes, the verbs and resources in its RBAC bindings), assume every one of those actions is taken at once, and describe what would break. If the identity can exec into a pod or hold a cluster-wide role, the honest answer is usually 'everything in the cluster'.
What is the difference between blast radius and least privilege?: Least privilege is the practice; blast radius is the measurement. Least privilege tells you to grant the minimum access needed for the task. Blast radius tells you how well you did: it is the damage still possible after the grant. You can follow least privilege and still have a large blast radius, because the minimum access a task genuinely requires is sometimes very broad.
Does Kubernetes RBAC limit blast radius?: It can, but only to the extent that the roles are actually narrow. RBAC is expressive enough to permit one verb on one resource in one namespace. In practice most teams bind broad built-in roles because narrow ones are laborious to write and maintain, and a broad role scoped to a namespace still leaves the whole namespace inside the blast radius.

Sources

Kubernetes RBAC documentationThe verb, resource, and namespace model that a Kubernetes blast radius is measured in.
NIST Computer Security Resource Center glossaryThe standard definition of least privilege, the practice that blast radius measures.

Last reviewed 13 July 2026.

None of this needs a credential on your laptop.

Spellbook packages the dangerous operations so the people who run them hold nothing. It is not open yet.

Join the waitlist