8 Kubernetes Security Misconfigurations That Make It to Production (And How to Fix Them)

vijaykanth1729 — Fri, 22 May 2026 13:50:13 +0000

After reviewing Kubernetes manifests across multiple production environments,
I keep seeing the same issues. These aren't edge cases — they're in most
clusters I've touched.

Here are the 8 most common ones, why they matter, and the exact fix.

1. Container Running as Root

What it looks like:

containers:
  - name: api
    image: nginx:latest

No securityContext defined = runs as root by default.

Why it matters: If an attacker gets shell access inside the container,
they have root privileges. Combined with a volume mount, this can mean
full host access.

Fix:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false

2. Missing Resource Limits

No resources.limits means one misbehaving pod can consume all node
resources — taking down everything else on that node.

Fix:

resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 128Mi

3. Using :latest Image Tag

:latest is mutable. Two pods on different nodes can be running
different versions of your image without you knowing.

Fix: Pin to digest or specific version:

4. No Liveness or Readiness Probes

Without probes, Kubernetes sends traffic to pods that aren't ready
and doesn't restart pods that are deadlocked.

Fix:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

5. Secrets in Plain Text Environment Variables

env:
  - name: DB_PASSWORD
    value: "mysecretpassword"  # visible in pod spec, logs, kubectl describe

Fix: Use secretKeyRef:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

6. No Network Policies

By default, every pod can communicate with every other pod in the cluster.
Zero segmentation.

A compromised frontend pod can directly query your database pod
unless you have NetworkPolicy defined.

7. Writable Root Filesystem

Without readOnlyRootFilesystem: true, an attacker with shell access
can modify binaries inside the container.

Fix:

securityContext:
  readOnlyRootFilesystem: true

8. ClusterRoleBinding to cluster-admin

Giving a service account cluster-admin is the Kubernetes equivalent
of chmod 777. Seen this in production more times than I can count.

Fix: Use the principle of least privilege — bind only the specific
verbs and resources the service account actually needs.

How I Scan for These Automatically

I got tired of manually reviewing manifests for these same issues,
so I built a scanner that checks for all of them automatically.

Paste your YAML or connect a GitHub repo → findings in under 3 seconds,
mapped to CIS Kubernetes Benchmark 1.8.

Free to try: deploypilotai.automationvijay.site

Which of these do you see most often in your clusters?
Any I missed that should be on the list?

DEV Community: vijaykanth1729

8 Kubernetes Security Misconfigurations That Make It to Production (And How to Fix Them)

1. Container Running as Root

2. Missing Resource Limits

3. Using :latest Image Tag

4. No Liveness or Readiness Probes

5. Secrets in Plain Text Environment Variables

6. No Network Policies

7. Writable Root Filesystem

8. ClusterRoleBinding to cluster-admin

How I Scan for These Automatically