Kubernetes Security Misconfigurations: A Practical Checklist

A Kubernetes manifest that deploys cleanly and passes every functional test can still be a security problem - because nothing about a container running as root or a pod with no resource limits looks obviously wrong in a normal code review.

Containers Running as Root

Without an explicit securityContext, a container runs as root by default - meaning a container escape vulnerability hands an attacker root on the underlying node, not just a limited user. The same root-by-default risk starts at the image itself , well before the manifest is ever applied.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false

Missing Resource Limits

A pod with no CPU/memory limits can consume unbounded resources on its node - whether from a genuine traffic spike or a runaway process - starving every other workload scheduled there. This is an availability risk that looks identical to a normal capacity problem until you trace it back to one misbehaving pod with no ceiling.

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Overly Broad RBAC

A ClusterRole granting * on * resources - copied from a tutorial and never scoped down - gives a workload far more access than it needs. If that workload is ever compromised, the attacker inherits every permission it was granted, cluster-wide.

• Grant only the specific verbs and resources a workload actually calls, not a blanket wildcard.
• Prefer a namespaced Role over a ClusterRole when the workload only needs access within one namespace.

Secrets Mounted as Plain Environment Variables

Kubernetes Secret objects are only base64-encoded, not encrypted, by default - and a secret exposed as a plain environment variable is visible to anything that can read the pod spec or trigger a crash dump that includes the process environment. It's the same exposure risk as a secret committed to Git history - recoverable long after it looks like it's been cleaned up. A dedicated secrets manager, or at minimum mounting secrets as files rather than environment variables, reduces this exposure surface.

Why These Pass Code Review

None of these mistakes cause a deployment to fail or a test to break - the workload runs correctly either way. That's exactly why automated scanning of manifests before they're applied matters, the same way a security scan report catches issues a manual review misses: a human reviewer checking "does this work" has no natural reason to also check "does this default to root" unless they're specifically looking for it.