Kubernetes Security: A Founder's Guide to a Full-Time Job (2026)

The Cluster I “Secured” for a Product With Zero Users

I’ve already confessed, in the Kubernetes architecture post, to the weekend in 2023 when I spun up a real cluster for Clickly — my URL shortener with exactly zero users. I felt like a genius for four hours, then tore it all down. I’d built a spaceship to deliver a pizza.

What I didn’t tell you is that before I tore it down, I got paranoid. Because I’m Indian and paranoid, and because I’d just read about a crypto-miner that found an open cluster and quietly rented the owner’s servers to mine coins on his card. So I spent a chunk of that Sunday trying to secure the thing. Lock down the dashboard. Figure out what RBAC meant. Stop my “Hello World” pod from being able to do anything it wanted.

That afternoon is why I can write this honestly. Kubernetes security isn’t a checkbox you tick at the end — it’s a second product, with its own vocabulary, its own failure modes, and its own full-time specialists who get paid a lot precisely because it’s that hard. I’ll walk you through the real attack surface, then give the same verdict I always give: for almost everyone reading this, the smart move is to never own it.

---

Why This Is Its Own Job

Here’s the thing nobody says out loud when they tell you to “just run Kubernetes.” The moment you provision a cluster, you inherit a distributed system with more moving parts than your actual product — and every one of those parts is a door.

When you deploy on Railway or Fly.io, someone else’s security team owns the control plane, the network fabric, the host patching, the whole substrate. You own your app and its secrets. That’s it. When you run your own cluster — even a managed one like EKS or GKE — the provider secures the control plane’s infrastructure, but everything inside the cluster is suddenly your problem: who can talk to the API, what each pod can do, how secrets are stored, whether a popped container can reach everything else.

And attackers know new clusters are soft. There’s a widely-cited finding that a fresh, exposed cluster gets its first automated attack attempt within about 18 minutes of going live — bots scan the internet for open Kubernetes API ports all day. Being small isn’t protection; it’s why you’re a target, because small teams misconfigure things and nobody’s watching the logs. Over 60% of Kubernetes breaches trace back to plain misconfiguration, not some exotic zero-day. The danger isn’t that Kubernetes is insecure. It’s that securing it correctly is a skill, and you don’t have it yet.

So let me show you the doors.

---

The API Server and etcd: The Front Door and the Vault

Everything in Kubernetes goes through one component: the API server. Every kubectl command, every controller, every pod checking in — all of it flows through that single front door, which makes it the first thing an attacker wants.

The classic mistake is exposing it to the public internet with weak authentication — or worse, leaving anonymous access on. Attackers scan for open API ports all day, then try to authenticate as the default service account and just… look around. If your cluster lets an unauthenticated request list resources, you’ve handed a stranger a map of your entire system.

Behind the API server sits etcd — the key-value store that holds the entire state of the cluster. Every config, every setting, and critically, every secret. If the API server is the front door, etcd is the vault. And most tutorials skip this: by default, everything in etcd is stored in the clear. Which brings us to the single most misunderstood fact in all of Kubernetes.

---

Secrets Are Just Base64 (Read That Again)

Kubernetes has an object literally called a Secret. You put your database password in it, your API keys, your payment processor tokens. The name gives you a warm feeling of safety.

That feeling is a lie.

By default, a Kubernetes Secret is not encrypted. It’s base64-encoded. Base64 is not encryption — it’s not even obfuscation. It’s the same reversible encoding your browser uses to stuff an image into a URL. Anyone who can read the Secret object, or who gets access to etcd, can decode it back to plaintext in one command. It just looks scrambled to a human glancing at it.

Encryption at rest exists, but it’s opt-in. You have to configure an EncryptionConfiguration on the API server yourself, ideally wired to a real key-management service (AWS KMS, Google Cloud KMS, or a tool like HashiCorp Vault). It ships off by default for backward compatibility — a polite way of saying the safe default was sacrificed so nothing breaks on upgrade. If you never knew to turn it on, your “secrets” have been sitting in etcd in effectively-plaintext this whole time.

---

RBAC: The Thing Everyone Gets Wrong

RBAC — Role-Based Access Control — is how Kubernetes decides who’s allowed to do what: who can create pods, read secrets, touch which namespace. Done right, it’s the seatbelt that stops one compromised component from wrecking the whole cluster. Done wrong — which is the norm — it’s a force multiplier for every breach.

The principle is least privilege: give each user, and each pod’s service account, the absolute minimum permissions it needs and not a scrap more. The reality: people grant broad permissions because it’s faster and everything “just works,” then never tighten them. Kubernetes even auto-mounts a service account token into every pod by default, so a container that gets popped often comes with a valid credential to talk back to the API server.

And the failure mode that catches smart people is that individually harmless permissions combine into a disaster. The textbook example: give a service account create on pods and get on secrets in the same namespace — each looks reasonable alone — and an attacker can schedule a pod that mounts your most sensitive secret as a volume and reads it straight out. Neither permission screamed “danger” on its own. Together they’re a privilege-escalation ladder.

Getting RBAC right means reasoning about the whole graph of who-can-reach-what, across every namespace, forever, as your app changes. That’s not a task, it’s a discipline — the kind a platform team obsesses over, and the kind a solo founder gets wrong at 1 AM while trying to ship a feature.

---

The Network Is Flat, and the Pods Trust Each Other

Here’s another default that surprises people: out of the box, every pod in a Kubernetes cluster can talk to every other pod. The network is flat. There’s no firewall between your public-facing web container and your internal database container unless you build one.

That means if an attacker compromises one low-value pod — say, a leaky image-processing service — they can immediately try to reach everything else: your database, your internal APIs, the API server itself. This lateral movement is how a small app-layer bug becomes a full cluster compromise, and in nastier cases a pivot all the way into the cloud account behind the cluster.

The fix is network policies — rules that say “this pod may only receive traffic from that pod.” But Kubernetes doesn’t enforce them itself; you need a networking layer that implements them, like Cilium (the popular eBPF-based one) or Calico. So now you’re installing and maintaining yet another security plugin — another product bolted onto your product.

Pods have their own footguns. A pod running as root, or as a “privileged” container with host access, is a container escape waiting to happen. Kubernetes replaced the old PodSecurityPolicy (gone since v1.25) with Pod Security Admission — three levels (Privileged, Baseline, Restricted) you switch on with a namespace label. Better than before, but you still have to know it exists and apply it. The default is permissive.

---

The Supply Chain: You’re Running Other People’s Code

The last door is the one you open before the cluster even starts: the container images themselves. Every image is somebody else’s code — a base OS, libraries, dependencies — and any of it can carry a known vulnerability straight into your cluster, running with network access to everything. Two habits matter, and both mean adding more tooling:

• Scan your images before they ship. Trivy (open-source, from Aqua Security) scans images for known CVEs, misconfigurations, and leaked secrets, and slots into your CI pipeline. Genuinely great — and one more thing to run, tune, and act on.
• Watch what runs at runtime. Falco, a CNCF graduated project, watches kernel-level system calls and flags suspicious behavior — a shell spawning inside a container, a container escape attempt. Again: excellent, and again: a whole subsystem to operate.

There’s a policy layer on top of all this too — tools like Open Policy Agent to enforce rules like “no container runs as root, ever” across the cluster. Every one is a good tool, and every one is another product, another dashboard, another thing that breaks. That’s the shape of the domain: security is achievable, but it’s assembled from a dozen specialist pieces, and keeping them all correct is the job.

---

The Broken Engineer Verdict: Don’t Own This Surface

So here’s the take I earned that paranoid Sunday: securing Kubernetes is a genuine full-time specialty — and that’s the single strongest argument against a solo founder running it at all.

Think about what we just walked through. Encrypt etcd, lock down the API server, keep a least-privilege RBAC graph correct forever, wire up a KMS, install a network-policy layer, set pod security levels, scan every image, watch runtime behavior. Each is a real project. Together they’re a job title — one that pays six figures because companies genuinely need people who do only this.

You are not that person, and you shouldn’t have to be. Your problem isn’t “how do I harden a control plane.” It’s the same one it always was: does anyone know your product exists. Every hour spent debugging why a network policy broke your app is an hour you didn’t spend getting a user. This is the exact trap I warned about with AWS and with Kubernetes architecture — complexity that feels like real work while quietly being the opposite.

The way out is the same door I always point at. When you deploy on Railway, Fly.io, or Koyeb, almost this entire attack surface evaporates — not because it stopped mattering, but because someone whose actual job is security now owns it. No API server you exposed by accident, no flat pod network, no etcd sitting in plaintext. You get a git push, a URL, and a company with a security team standing behind the substrate. You still secure your app — your auth, your dependencies — but not a data center’s worth of infrastructure you don’t understand. (Still torn on whether you even need containers? Docker vs Kubernetes settles which layer earns its place.)

And if you genuinely must run Kubernetes — you inherited a cluster, you’re paid to know this, your company standardized on it — then learn every door in this post, become (or hire) the specialist, and treat security as the ongoing product it is. Respect the tool. Just don’t take it on by accident because a conference talk made it sound mandatory.

---

The thing I actually learned that Sunday wasn’t how to configure RBAC. It was that a friendly name like “Secret” can hide a plaintext string, and that the safest cluster I ever ran was the one I deleted an hour later. Kubernetes security is real, deep, and a beautiful discipline for the people who choose it. You didn’t. You chose to build a product. So let someone else guard the port, and go find the one human who wants what you made.

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and hand you the scars so you can skip them. Now close the security docs and go get a user.