The Kubernetes Security Journey, Mapped End to End

Forty-one topics in, here's the thing I'd tell the version of me who started this: you don't secure a cluster by collecting features. I learned the controls one at a time, RBAC, then network policy, then seccomp, then admission webhooks, and the honest lesson is the opposite of a checklist. Security lives in how the layers stack. Any single control is one bypass away from not mattering, and a cluster with a perfect read-only filesystem and a wide-open RBAC role is not a secure cluster, it's a tidy one.

So this last one isn't a new topic. It's the map. If you've inherited a cluster nobody documented, or you're grinding the CKS, or you just want the whole series in one place instead of forty tabs, this is the page to bookmark. I've grouped every topic two ways, by the path an attacker actually walks and by the defence it belongs to, and pointed each at the write-up and the hands-on Kubernetes pentest notes. That's the finale. The journey moves to AI and LLM security next, but the cluster work stands on its own, and this is where it all connects.

The map by the attacker's path

If you only ever read one framing of cluster security, make it this one. An attacker doesn't care about your org chart of controls, they move in a line: get in, work out what they can do, escalate, break out to the node, then stay. Here's the series laid along that line, so you can see which control sits at which hop.

Getting in is usually the platform's exposed edges or the app on top. An exposed kubelet is straight RCE on the node, an exposed Docker daemon is root on the host, and kubectl proxy and port-forward are the quiet shortcuts people forget they left open. Node metadata is the one that slips through because it isn't a bug, it's a feature that hands out cloud credentials.

Enumerating comes down to identity. The whole of Kubernetes authorization is a pipeline, not one gate, and it hangs off what a token is: a kubeconfig is a credential wearing a config file's clothes, minted through authentication and TLS and PKI. A ClusterRole is just a Role that forgot its namespace, which is exactly how enumeration turns into escalation.

Escalating is where least privilege earns its keep, or doesn't. Most escalations are an RBAC verb someone shouldn't hold, a service-account token mounted where it shouldn't be, or a pod allowed to run privileged. Breaking out to the node is the node attack surface, Linux privilege escalation, and the container boundary itself, which brings in syscalls, the shared kernel, and the confinement layers below. Persisting is cloud IAM off the node role, a hidden binding, or a mutating webhook, all of which are in the pentest notes now, ninety of them, phase by phase.

The map by defence

Same forty-two topics, sorted the way a defender builds. If you're hardening a real cluster, work down this list roughly in order, because each layer assumes the one above it holds.

Foundations, and the model

You can't threat-model a thing you don't understand, so the series opens with the plumbing: what Kubernetes is, the mental model that makes it click, and nodes and workloads. Then the security frame itself, the 4Cs of cloud native security with a real attack chain, and CIS benchmarks with kube-bench, which turns "is this secure" from a vibe into a score.

Identity and access

This is the one that matters most, and the one people rush. Authentication (static credential files are a trap), TLS and PKI, the kubeconfig, the authorization pipeline, cluster roles and bindings, and least privilege done properly, starting at zero and adding back slowly.

The API server and components

The control plane's own exposed surfaces: the kubelet, kubectl proxy and port-forward, and how to verify binaries and upgrade in order so you don't trust a tampered component.

Network

Kubernetes pods talk to everything by default, which is the single most surprising default for anyone new. Ingress gives many services one URL and one cert, and one place to get the TLS wrong.

Node and host hardening

Under every pod is a Linux box that needs the basics: SSH hardening (the default leaves the front door on the latch), sudoers privilege escalation, the node attack surface a fresh box ships with, least privilege two ways with cloud IAM and a host firewall, and audit logging so someone can actually say who deleted that Deployment.

Runtime confinement

How much a container can do once it's running. Every action goes through one kernel door, so you filter it: seccomp (Docker filters syscalls by default, Kubernetes doesn't), AppArmor and capabilities for the files seccomp can't see, and gVisor and Kata when sharing the kernel isn't good enough.

Admission control and policy

The gate RBAC never opens. Admission controllers read the pod spec, validating and mutating webhooks let you write your own checks, Pod Security Policies are gone and the replacement is better, and OPA Gatekeeper makes policy code you can test.

Secrets, TLS and multi-tenancy

Kubernetes Secrets are not secret (base64 isn't encryption), one-way TLS versus mTLS decides which end has to prove itself, and multi-tenancy is where it all gets tested: a namespace is a label, not a wall, isolation is a stack most clusters half-build, and fairness where a quota is a ceiling, not a referee.

Supply chain and runtime detection

What you ship and what watches it run. Your scanner doesn't delete anything, a manifest that applies isn't safe, Kubernetes trusts every registry online by default, Falco catches what static checks can't, and a read-only root filesystem isn't the immutable container it's sold as.

If you only read five

Forty-two is a lot, and not all of it is equally urgent. If you're staring at a cluster tomorrow morning with an afternoon to spend, these are the five I'd read first, because they cover the ground most real incidents actually walk.

The one thing to run tonight

If this is you, you've got a cluster you didn't build and you're not sure where the holes are, don't start by reading. Start by measuring. Two commands tell you more than an hour of guessing. Score the cluster against the benchmark, then list every container running with a writable root disk:

kube-bench run --benchmark cis-1.8

kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.metadata.namespace}{"/"}{.name}{"\t"}{.securityContext.readOnlyRootFilesystem}{"\n"}{end}{end}' | grep -vE 'true$'

The FAILs are your reading list, in priority order, and the second command's output is the pods to fix first. That's a real afternoon of work off two commands, and it's the honest way to start on any cluster you've inherited.

I'll be straight about the limits of my own map. I'm employed elsewhere and I learned most of this in a homelab, on kind and a few VMs, not across years of production incidents, so treat the ordering as one careful practitioner's, not gospel. The topic I got most wrong the first time was the Pod Security one, I'd written PodSecurityPolicy as current before catching that it was pulled in 1.25, which is exactly the kind of stale advice this series tried not to be. If your production experience says I've weighted something wrong, I'd genuinely like to hear it. And if you're the person who owns one of these clusters and this guide made you want a second pair of eyes on the RBAC or the admission setup, that's the conversation I enjoy most, so say hello. No pitch, I'm learning in public and comparing notes is the whole point.

That's the Kubernetes Journey done, forty-two topics and a ninety-note playbook that'll keep growing. Next I'm turning the same "how does this actually break" lens on AI and LLM security, which is a newer, messier attack surface and, honestly, the one I'm most curious about right now. Same approach, different target. See you over there.

References

• The full Kubernetes Journey index (all 42 topics)
• The Kubernetes pentest notes (90 operator notes, phase by phase)
• Kubernetes docs: the security overview
• kube-bench: the CIS benchmark scanner
• Kubernetes docs: Pod Security Standards

FAQ

Where should I start with Kubernetes security?

Start with the authorization pipeline and RBAC, because most real attacks are an over-permissioned token, not a zero-day. Then score the cluster with kube-bench against the CIS benchmark, lock down the kubelet and the node, and only then move to admission control and runtime detection. Identity first, always.

What is the most common Kubernetes misconfiguration?

Over-broad RBAC, usually a ClusterRoleBinding where a namespaced RoleBinding would do, followed closely by pods that run as root with no read-only filesystem and no dropped capabilities. Both are boring, both are everywhere, and both turn a single foothold into cluster-wide access far more often than any exotic bug.

Do I need to read the Kubernetes series in order?

No. This guide groups all 42 topics by theme and by the attacker's path, so you can jump to whatever you're working on: RBAC, network policy, node hardening, admission control, secrets, multi-tenancy, supply chain or runtime. The pentest notes at /notes/kubernetes are the fast, command-first companion.

Is a read-only filesystem or seccomp enough to secure a container?

No single control is enough, that's the whole point of the series. Seccomp filters syscalls, AppArmor covers files, a read-only root stops disk writes, capabilities shrink kernel powers. Each one closes one door. Real security is the stack of them plus admission enforcement, not any single flag.

Related reading

• The RBAC pipeline (start here if you read nothing else)
• Topic 41: readOnlyRootFilesystem Isn't Immutable (the previous topic, and a good summary of the runtime mindset)
• The Kubernetes pentest notes (the command-first companion to this whole series)
• Browse the whole Kubernetes Journey