Kubernetes Security Reality Check

Most Kubernetes deployments are disasters waiting to happen. Not because the engineers are incompetent, but because secure-by-default isn't how K8s works.

Let me show you what I see when I audit production Kubernetes clusters.

What's usually broken

Containers running as root. Why? Because it's easier than figuring out file permissions. Result: compromised container gets root on the host.

No network policies. Everything can talk to everything. Pod gets compromised and suddenly it's scanning your entire cluster looking for lateral movement opportunities.

Secrets in environment variables or worse, hardcoded in images. Commit history full of API keys and database passwords.

Default service accounts with way too many permissions. Every pod can list all secrets in the namespace
because nobody bothered to configure RBAC properly.

Images pulled from Docker Hub with no verification. Could be the official nginx image. Could be nginx +
cryptominer. Who knows?

Why this happens

Kubernetes makes the easy things easy and the secure things hard. Getting a deployment running takes 5
minutes. Securing it properly takes 5 days of reading docs, understanding RBAC, configuring service mesh, setting up admission controllers.

Teams are optimizing for velocity. Ship features. Fix bugs. Hit deadlines. Security is "we'll harden it later" and later never comes because there's always another deadline.

The defaults are terrible. K8s was designed for flexibility, not security. You can secure it, but you have to opt-in to basically everything.

What actually matters

Run containers as non-root. Set runAsNonRoot- true in your security context. Yes, you'll have to fix file permissions. Do it anyway. The alternative is giving attackers root if they compromise anything.

Implement network policies. Default deny everything. Then explicitly allow only what's actually needed. Service A needs to talk to database? That gets an allow rule. Everything else? Blocked.

Use a service mesh. Istio, Linkerd, whatever. Gets you mutual TLS between services, traffic policies, and actually understanding what's talking to what. Plus it makes network policies less painful to manage.

Actually configure RBAC. Every pod should have its own service account with minimal permissions. "View pods in this namespace" not "admin access to the entire cluster."

Scan everything. Images before they deploy. Running containers for runtime behavior. Use Trivy in CI/CD. Use Falco in production. Both are free and actually work.

Secrets management. Get them out of environment variables. Use sealed secrets, external secrets operators, or vault. Anything but environment variables and ConfigMaps.

Admission control. Use OPA or Kyverno to enforce policies at deploy time. No root containers? Policy rejects them. Missing security context? Can't deploy. This catches problems before they reach production.

Real-world example

Audited a fintech running 500 services on Kubernetes. Found containers running as root, no network
segmentation, and default service accounts everywhere. Their argument: "But it works and we haven't been breached."

Ran a red team exercise. Compromised one pod through a vulnerable dependency. From there: pivoted to every service in the namespace because no network policies. Escalated to cluster admin because default service account had excessive permissions. Extracted database credentials from secrets that any pod could read.

Total time: 45 minutes from initial compromise to full cluster control.

We rebuilt their security posture from scratch. Non-root containers. Network policies. Proper RBAC. Service mesh for east-west encryption. Admission policies enforcing standards.

Ran the red team exercise again. This time when we compromised the same pod: couldn't talk to other services due to network policies. Couldn't escalate privileges due to proper RBAC. Couldn't read secrets due to service account restrictions. Couldn't deploy backdoors due to admission control.

Attack stopped cold.

The hard truth

Kubernetes security requires up-front investment. You can't bolt it on later without breaking things.

Start with security from day one, even if it slows you down initially. Because going back and hardening a
production cluster while keeping everything running is 10x harder.

And for anyone thinking "we're too small to be a target": ransomware doesn't care about your size.
Cryptominers don't care about your size. Automated attacks don't care about your size.

Secure your clusters now, or spend 2am on a Saturday cleaning up after a breach. Your choice