Admission

Alright, let’s talk about the grown-ups in the room for policy enforcement: OPA/Gatekeeper and Kyverno. You’ve got your Pod Security Standards, but they’re just that—standards. They’re a list of “thou shalts” and “thou shalt nots” sitting on a website. To actually enforce them in your cluster, you need a bouncer. That’s what these policy engines are. They’re admission controllers that intercept requests to the Kubernetes API server and say, “Nope, not gonna happen,” based on rules you define. Forget boring manual checks; this is where you automate your cluster’s law and order.

Right, let’s talk about making your containers less of a welcome mat for attackers. You’ve got your Pod Security Admission set up, maybe you’re even using a Restricted policy. Good. But that’s just the bouncer at the club door checking the dress code. Seccomp and AppArmor are the bouncers that actually frisk you, making sure you’re not bringing in any shady system calls or file access patterns. They are, without a doubt, two of the most effective tools in your runtime security arsenal. And yes, I know their names sound like rejected Star Wars characters, but bear with me.

Right, so you’ve got your shiny new Pod Security Standards. You know what Restricted means, you’re nodding along with Baseline. But knowing the rules is useless if your cluster isn’t actually enforcing them. That’s where Pod Security Admission (PSA) comes in. Think of PSA as the no-nonsense bouncer for your namespaces, checking every Pod’s ID against the guest list you provide. It’s built directly into the Kubernetes API server, so it’s not some external thing you have to manage; it’s just there, waiting for you to tell it what to do.

Right, let’s talk about Pod Security Standards. This is where we move from the abstract, hand-wavy world of “you should secure your pods” to the concrete, “here’s exactly what that means” rules of the road. The PSS are a set of three predefined security profiles that give you a sane, graduated path from “let’s just get it running” to “Fort Knox on a good day.” Think of them as the security settings on your phone: Privileged is the developer mode you use once and regret, Baseline is the default that stops the most egregious nonsense, and Restricted is the “max security” that makes your phone ask for a fingerprint to change the volume. Kubernetes needed this because the default security posture was, frankly, a carnival ride designed by a madman. You could do anything. The PSS are the safety harnesses.

Let’s be brutally honest: you run a container in privileged mode for the same reason you give a toddler a power tool—because you’re either performing a very specific, dangerous task under close supervision, or you’re about to have a very, very bad day. A privileged container is essentially a process on your host node that has politely asked the kernel for its entire set of privileges, and the kernel, like a tired parent, has said “Fine, whatever, just don’t break anything.”

Right, let’s talk about capabilities. This is where we stop treating a container like a dumb binary and start treating it like a process running on a Linux kernel, which is exactly what it is. The all-or-nothing model of “run as root” or “run as non-root” is brutally simplistic. Sometimes a process just needs to do one privileged thing, like bind to a port below 1024. Giving it full root access to do that is like giving someone the master key to the entire building because they need to get into the supply closet. It’s absurd.

Right, let’s talk about the three amigos of Pod security that actually do something useful at runtime: runAsUser, runAsNonRoot, and readOnlyRootFilesystem. This isn’t abstract policy stuff; this is the kernel-level nitty-gritty that stops an attacker who’s already inside your container from doing something truly stupid. Think of this as the final, desperate line of defense after someone has already kicked the front door in. First, a dose of reality. These settings live in your Pod’s securityContext or container’s securityContext. The Pod-level one sets the default for all containers, but the container-level one overrides it. My advice? Be explicit at the container level. You’ll thank me later when you’re not debugging why one weird container is behaving differently from the other seven in the Pod.