Cis-Benchmark

Right, let’s talk about supply chain security. You’ve probably heard the term “software supply chain” and thought, “That sounds… corporate. And boring.” I get it. But think of it this way: you’re not just running apt-get install or pulling a random container image anymore. You’re becoming a curator, a verifier, a detective. You’re building a chain of evidence from the original developer’s keyboard all the way to your production cluster. And the goal is to stop some chucklehead from slipping a backdoor into your application because you blindly trusted a base image from the internet. We’re going to use two tools to build this chain: SLSA (the blueprint) and Sigstore (the notary public).

Alright, let’s talk about tightening the screws. You’ve got a pod running. Great. But right now, by default, it’s probably a digital hoarder’s dream, packed with capabilities it has no business having. Our goal is to turn it into a minimalist’s paradise. We’re going to strip it down to only what it absolutely needs to function. This isn’t about being mean to your application; it’s about being ruthless on its behalf. If an attacker breaks in, we want them to find a beautifully empty room with no tools to escalate their privileges or move laterally.

Alright, let’s talk about secrets. Not the salacious kind, but the ones that make your cluster go. API tokens, database passwords, TLS certificates—the digital crown jewels. The problem is, by default, Kubernetes doesn’t treat them with the gravitas they deserve. A Secret is just a base64-encoded string sitting in etcd. It’s like writing your password on a post-it note and then just turning the note upside-down. We’re going to do a lot better than that.

Right, so you’ve got your cluster up. It’s running. You’ve hopefully locked down the API server, you’re using RBAC like a responsible adult, and your network policies are tighter than a submarine’s door. Good. But here’s the uncomfortable truth: that’s all preventative security. It’s the castle walls and the moat. It assumes the bad guy is still outside. What happens when someone, through a clever exploit or a horrifying credential leak, gets inside? You need a guard who walks the halls, listens at doors, and shouts “HEY, THAT’S WEIRD” at the top of their lungs when they see something they don’t like. That guard is Falco.

Let’s be honest: your container images are the front door to your cluster, and right now, you’re probably leaving the key under the mat. You wouldn’t run curl http://strange-website.com | sudo bash on a production server, but if you’re pulling random, unsigned images from public registries, you’re doing the containerized equivalent. The image is the one artifact that contains everything that will run, from your brilliant application code to a forgotten, vulnerable curl binary from 2014. Securing this isn’t just a good idea; it’s the absolute bedrock. We’ll tackle this in three parts: making sure your images aren’t full of holes (scanning), proving they came from you and not an imposter (signing), and controlling where you get them from (trusted registries).

Right, let’s talk about making your containers less of a liability. You’ve probably heard the phrase “defense in depth” until you’re sick of it. I get it. But this is one of those beautifully simple, “why wouldn’t you?” layers. The concept is stupidly simple: if a process inside your container has no business writing to the filesystem, don’t let it. At all. This isn’t just about protecting your precious application code; it’s about neutering a huge vector of attack. If an attacker breaks in, they can’t download tools, they can’t write scripts, they can’t persist. It turns a potential nightmare into a fleeting nuisance.

Right, let’s talk about one of Kubernetes’ more “helpful” defaults that is, frankly, a bit of a security nightmare. When you create a Pod, and you haven’t explicitly said which ServiceAccount it should use, Kubernetes, like a overly accommodating butler, says “Not to worry, sir/madam, I shall assign the default ServiceAccount from this namespace.” And then, without asking, it also automatically mounts that ServiceAccount’s API token into the Pod at /var/run/secrets/kubernetes.io/serviceaccount/token.

Right, the CIS Benchmark. Think of it not as a suggestion box, but as the collective, grumpy wisdom of every engineer who’s ever been paged at 3 AM because of a misconfigured kubelet. It’s a checklist of “please, for the love of all that is holy, do this so you don’t end up on a news website.” We’re not going to cover every single control—that’s a book in itself—but we’ll hit the high-impact, “why hasn’t this been the default?” ones that you can implement today to stop the metaphorical bleeding.