In a Kubernetes hardening benchmark, how do you tell an item that removes a technique from one that only narrows it?

## The test Every item in a hardening standard can be sorted with the same three-step test, and it is worth doing out loud in an interview because it shows you reason about the adversary rather than the list. 1. **Name the technique.** Not "attacks" — a specific thing somebody does: run a command inside a container on a node without holding any credential; use a container's own identity to talk to the cluster API; schedule a workload that mounts the host filesystem. 2. **Name what it consumes.** Every technique consumes something: a reachable unauthenticated endpoint, a credential that was handed to the process, an admission path that accepts the object being asked for. 3. **Ask whether that thing still exists after the item is applied, and whether anything substitutes for it.** If nothing substitutes and the adversary must first obtain something they do not have, the item **removes**. If they keep going at slightly higher cost, or by asking for slightly less, it **narrows**. ## Removal, worked The node agent on each Kubernetes node serves an HTTPS API that can list the pods on that node, stream container logs and execute commands inside containers. Left with anonymous authentication enabled and a permissive authorization mode, that API answers a caller who presents nothing at all. An adversary who can route to the node's port has, at that point, command execution inside every container on the node. Turn anonymous authentication off and the technique has no remaining path. There is no weaker variant of "present nothing" — the caller must first acquire a credential the API will accept, which is a different technique, with its own prerequisite and its own cost. This is what load-bearing means: the item removes the thing the technique cannot substitute. Note also that this is the item most likely to already pass, because common provisioning tooling ships it disabled. Load-bearing and already-satisfied are not opposites; the item is still the roof, you simply did not build it. ## Narrowing, worked An item requiring containers to run as a non-root user reads like a big change and often is not. Consider an adversary who already has code executing in a container. What do they lose? The root-only actions inside that container: installing packages, writing to system paths in the image, some privileged operations against the runtime. What do they keep? Everything the technique they care about consumes — the service-account credential mounted into the pod, the ability to make outbound connections, the ability to read whatever the application could read. The technique "use this workload's own identity against the cluster API" is untouched, because it never needed root. That is narrowing: the adversary pays a little more, or asks for slightly less, and continues. The same shape shows up whenever a policy constrains a *request* rather than an *ability*. A workload owner who is told they may not have a privileged container frequently comes back with a request for the narrower thing they actually needed, it is admitted, and the technique that mattered survives the negotiation. ## The two buckets nobody counts - **Removes nothing any adversary does.** Items about file ownership on control-plane nodes are meaningful if you run those nodes and meaningless if your control plane is operated by somebody else and you have no shell on it. Items about naming, paths or optional components you never installed are in the same bucket. They exist because the standard must apply to every reader. - **Already satisfied by the shipped default.** These pass on day zero. They are worth keeping, because a default can change and drift is real, but they are not a change in exposure and must not be presented as one. ## Why the sort matters Because the score does not do it for you. The list is unweighted: a removal, a narrowing, an irrelevance and a freebie each contribute one item. Any conversation that starts from the percentage rather than from the sort will get the estate's priorities wrong in whichever direction the arithmetic happens to point. ## The trap in the test Be careful about declaring removal from the item's wording rather than from the adversary's position. "Turn off automatic mounting of the service-account credential into pods" sounds like a removal, and it is one for an adversary whose whole plan was to read that credential out of the filesystem. It is nothing at all if the identity in question was never granted anything useful, and it is only a narrowing if the same workload obtains a credential another way. The verdict is a property of the item *and* the estate *and* the adversary's starting position — never of the item alone.