Kubernetes misconfigurations caused 31% of cloud security incidents reported to us in 2024. The most common finding is not exotic — it's containers running as root, overly permissive RBAC, and network policies that allow unrestricted pod-to-pod communication. The good news: all three are fixable with tooling that exists today.
The five highest-risk misconfigurations
- 1.Containers running as root (UID 0): a container escape in a root-privileged container gives the attacker node-level access. Use runAsNonRoot: true in your security context.
- 2.Wildcard RBAC permissions: ClusterRoles with verbs: ["*"] or resources: ["*"] violate least privilege. Audit with kubectl auth can-i --list for every service account.
- 3.Exposed Kubernetes dashboard without authentication: we still see this regularly. It provides cluster-admin access via a browser. Disable it or enforce OIDC.
- 4.Default service account token auto-mounting: every pod mounts a service account token by default. For pods that don't need API access, set automountServiceAccountToken: false.
- 5.Missing network policies: without explicit NetworkPolicy objects, all pods can communicate with all other pods. Define default-deny ingress and egress policies, then allow only what is needed.
Admission control as your last line of defence
Admission webhooks (OPA Gatekeeper or Kyverno) enforce policy at deployment time, not at runtime. This is the correct place to catch misconfigurations before they reach production. A policy that rejects privileged containers at the admission layer prevents the misconfiguration from ever existing in the cluster.
# Kyverno policy: disallow root containers
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-root-containers
spec:
validationFailureAction: Enforce
rules:
- name: check-runAsNonRoot
match:
resources:
kinds: [Pod]
validate:
message: "Containers must not run as root."
pattern:
spec:
containers:
- securityContext:
runAsNonRoot: trueRuntime protection: what admission control misses
Admission control catches known-bad configurations at deploy time. Runtime protection catches unexpected behaviour after deployment: a container that starts making unexpected system calls, spawning shells, or connecting to new external IPs. Use Falco or the ShieldOps K8s runtime sensor for this layer.
etcd stores all cluster state including secrets in base64 (not encrypted by default). Enable encryption at rest for secrets, restrict etcd access to the API server only, and back up etcd to encrypted storage. A compromised etcd is a full cluster compromise.
Building a continuous posture management programme
Posture management is not a one-time audit — clusters change constantly. Run automated configuration checks on every deployment via your CI/CD pipeline, schedule weekly full-cluster scans, and integrate findings directly into your security platform so misconfigurations appear alongside runtime alerts with the same severity taxonomy.