Kubernetes Security: What Actually Matters in 2026

Three months ago, a company called me in a panic. Their Kubernetes cluster had been compromised. Cryptocurrency miners were running on every node. Their AWS bill had jumped from $8,000 to $43,000 in two weeks.

"But we followed the documentation," the CTO said. "We thought we were secure."

Turns out, they'd focused on the wrong things. They had network policies configured perfectly but left their API server exposed to the internet with default credentials. Classic.

Kubernetes security is overwhelming. There are hundreds of settings, dozens of best practices, and endless blog posts telling you everything is critical. It's not. Some things matter way more than others.

Let me tell you what actually matters based on responding to real incidents, not theoretical threats.

The API Server: Your Crown Jewel

If an attacker gets access to your Kubernetes API server, game over. They control everything. Every pod, every secret, every node. It's the keys to the kingdom.

Yet I see exposed API servers constantly. Last year alone, I found 12 clients with API servers accessible from the public internet. Twelve!

Lock Down API Access (Do This First)

Your API server should never be publicly accessible. Never. I don't care what your use case is.

Use a VPN or bastion host for administrative access. Use service accounts with minimal permissions for automated access. Use kubectl proxy for local development.

If you absolutely must expose it (and you probably don't), put it behind a firewall that only allows specific IP addresses. And enable audit logging so you know who's accessing it.

Enable RBAC (And Actually Use It)

Role-Based Access Control isn't optional. It's mandatory.

But here's the thing: most people enable RBAC and then give everyone cluster-admin privileges. That defeats the entire purpose.

Follow the principle of least privilege:

• Developers get access to their namespaces only
• CI/CD systems get just enough permissions to deploy
• Monitoring tools get read-only access
• Nobody gets cluster-admin unless they absolutely need it

I worked with a company where 47 people had cluster-admin access. Forty-seven! We got it down to 3. Guess what? Nothing broke. Nobody actually needed those permissions.

Learn more from Kubernetes RBAC documentation.

Audit Logging: Know What's Happening

Enable audit logging on your API server. This tells you who did what and when.

When that crypto mining incident happened, audit logs showed us exactly how the attacker got in (exposed API server), what they did (created privileged pods), and when it happened (2 AM on a Saturday).

Without audit logs, we would have been guessing. With them, we had a complete timeline.

Send your audit logs to a centralized logging system. Don't just leave them on the API server where an attacker can delete them.

Pod Security: Stop Running as Root

Here's a fun fact: most containers run as root by default. That's insane.

If an attacker compromises a container running as root, they have root access to that container. From there, they can often escape to the host node. Now they have root access to your entire node.

This isn't theoretical. Container escapes happen. I've investigated several.

Pod Security Standards (Use Them)

Kubernetes has Pod Security Standards that define three levels:

• Privileged: Unrestricted (dangerous)
• Baseline: Minimally restrictive (better)
• Restricted: Heavily restricted (best)

Start with baseline. Move to restricted for production workloads.

This prevents:

• Running as root
• Privileged containers
• Host network access
• Host path mounts
• Dangerous capabilities

One client had 200+ pods running in production. We applied restricted pod security standards. 180 pods failed to start. That's 90% of their workloads running with unnecessary privileges.

We fixed them all in a week. None of them actually needed those privileges. They just had them because nobody said no.

Security Contexts: The Details Matter

Every pod should have a security context that:

• Runs as a non-root user
• Uses a read-only root filesystem
• Drops all capabilities
• Disables privilege escalation

Here's what that looks like:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

Yes, this will break some applications. Fix the applications. Don't compromise security because your app wants to write to /tmp.

Network Policies: Control Traffic Flow

By default, any pod can talk to any other pod. That's a problem.

If an attacker compromises your frontend pod, they shouldn't be able to directly access your database pod. But without network policies, they can.

Implement network policies that:

• Deny all traffic by default
• Explicitly allow only necessary connections
• Isolate namespaces from each other
• Restrict egress traffic

This is defense in depth. Even if one pod is compromised, the attacker can't move laterally.

Learn more about Kubernetes Network Policies.

Secrets Management: Stop Using Kubernetes Secrets

Controversial opinion: Kubernetes Secrets aren't secure enough for production.

They're base64 encoded, not encrypted. Anyone with access to etcd can read them. Anyone with read access to secrets in a namespace can decode them.

For development? Fine. For production? Use a real secrets management solution.

External Secrets Operators (The Right Way)

Use tools like:

• AWS Secrets Manager with External Secrets Operator
• HashiCorp Vault
• Azure Key Vault
• Google Secret Manager

These provide:

• Encryption at rest
• Audit logging of secret access
• Automatic rotation
• Fine-grained access control
• Centralized management

Yes, it's more complex than Kubernetes Secrets. It's also actually secure.

One client had database credentials stored as Kubernetes Secrets. A developer with namespace access accidentally committed them to a public GitHub repo. Oops.

With a proper secrets manager, that wouldn't have been possible. The developer would have had access to use the secret, not read it.

Encrypt etcd (At Minimum)

If you must use Kubernetes Secrets, at least encrypt etcd at rest.

This prevents someone with filesystem access to your control plane from reading secrets directly from etcd.

It's not perfect, but it's better than nothing.

Image Security: Know What You're Running

You're running code from the internet in your production environment. Think about that.

Every container image is code. Code that could have vulnerabilities. Code that could be malicious. Code that you're trusting with your data.

Scan Everything (No Exceptions)

Scan every container image for vulnerabilities before deploying it. Use tools like:

• Trivy
• Snyk Container
• Anchore

Integrate scanning into your CI/CD pipeline. If an image has critical vulnerabilities, don't deploy it.

I scanned a client's production images last month. Found 347 high and critical vulnerabilities. Three hundred forty-seven! Some of them were 3 years old.

They'd been running vulnerable images in production for years because nobody was checking.

Use Minimal Base Images

The smaller your image, the smaller your attack surface.

Don't use ubuntu:latest as your base image. Use alpine or distroless images.

Example:

• ubuntu:latest: 77MB, hundreds of packages
• alpine:latest: 7MB, minimal packages
• distroless: Even smaller, no shell, no package manager

One client reduced their average image size from 500MB to 50MB by switching to distroless. That's 90% smaller. Faster deployments, smaller attack surface, lower storage costs.

Image Signing and Verification

How do you know the image you're deploying is the image you built?

Use image signing with tools like Sigstore or Notary.

This prevents:

• Deploying tampered images
• Supply chain attacks
• Unauthorized image modifications

Configure admission controllers to only allow signed images in production. If it's not signed, it doesn't run.

Runtime Security: Detect the Unexpected

Even with perfect configuration, things can go wrong. You need runtime security to detect and respond to threats.

Falco: Your Security Camera

Falco monitors your cluster for suspicious behavior:

• Unexpected process execution
• Suspicious network connections
• File system modifications
• Privilege escalation attempts
• Container escapes

It's like a security camera for your cluster. It won't prevent attacks, but it will tell you when they're happening.

I've seen Falco detect:

• Crypto miners starting in compromised pods
• Attackers trying to escape containers
• Malware downloading additional payloads
• Unauthorized access to sensitive files

All in real-time. That's the difference between detecting a breach in minutes versus months.

Admission Controllers: The Gatekeeper

Admission controllers intercept requests to the API server before objects are created. They can validate, mutate, or reject requests.

Use them to enforce policies:

• No privileged pods
• All images must be from approved registries
• All pods must have resource limits
• All pods must have security contexts

Tools like OPA Gatekeeper or Kyverno make this easy.

One client used admission controllers to enforce that all production pods must:

• Run as non-root
• Have resource limits
• Come from their private registry
• Have security contexts defined

Developers couldn't deploy non-compliant pods even if they tried. The admission controller would reject them.

Supply Chain Security: Trust But Verify

Your application depends on dozens or hundreds of third-party components. How do you know they're safe?

Software Bill of Materials (SBOM)

Generate an SBOM for every image. This is a complete list of all components in your image.

When a new vulnerability is announced (like Log4j), you can instantly check if you're affected by searching your SBOMs.

Without SBOMs, you're manually checking every application. With SBOMs, it's automated.

Tools like Syft generate SBOMs automatically.

Verify Dependencies

Don't just trust that npm package or Docker image. Verify it.

Use dependency scanning tools to check for:

• Known vulnerabilities
• Malicious packages
• License compliance issues
• Outdated dependencies

One client discovered they were using a compromised npm package that was exfiltrating environment variables. Dependency scanning caught it before it reached production.

The Reality Check: You Can't Do Everything

I've thrown a lot at you. If you try to implement everything at once, you'll fail.

Prioritize based on risk:

Critical (Do This Week):

• Lock down API server access
• Enable RBAC with least privilege
• Scan container images for vulnerabilities
• Enable audit logging

Important (Do This Month):

• Implement pod security standards
• Set up network policies
• Deploy runtime security monitoring
• Use external secrets management

Good to Have (Do This Quarter):

• Image signing and verification
• SBOM generation
• Advanced admission controllers
• Comprehensive security policies

Start with the critical items. They'll prevent 80% of attacks with 20% of the effort.

Measuring Success: Know If You're Secure

How do you know if your security efforts are working? Measure these:

Security Incidents

Track incidents over time. This should trend downward.

If it's not, either your security isn't working or your detection is improving (which is actually good).

Vulnerability Remediation Time

How long from discovering a vulnerability to fixing it?

Target:

• Critical: 24 hours
• High: 1 week
• Medium: 1 month

If you're slower than this, you're accumulating security debt.

Policy Compliance Rate

What percentage of your pods comply with security policies?

Target: 100% in production, 95%+ in non-production.

If you're below this, you have work to do.

Mean Time to Detect (MTTD)

How long does it take to detect a security incident?

Target: Under 5 minutes for critical issues.

The faster you detect, the less damage an attacker can do.

The Bottom Line

Kubernetes security is complex, but it's not impossible.

Focus on the fundamentals:

• Secure your API server
• Run pods with minimal privileges
• Scan and verify images
• Monitor runtime behavior
• Manage secrets properly

Do these well, and you'll be more secure than 90% of Kubernetes deployments.

Ignore them, and you're one misconfiguration away from being the next breach headline.

Need help securing your Kubernetes clusters? Let's talk. I've secured clusters for companies from startups to Fortune 500s. I can help you prioritize what matters and avoid wasting time on what doesn't.