The Kubernetes security risks that compromise real clusters are almost never novel exploits; they are misconfiguration, over-permissive access, exposed control-plane components, and vulnerable container images left to age. If you are worried about Kubernetes security risks, the most useful thing you can do is stop imagining exotic kernel zero-days and start auditing the boring configuration that attackers actually use. This guide ranks the threats by how often they cause incidents and gives you the concrete fix for each.
Risk 1: Misconfiguration is the default
Kubernetes is powerful and permissive out of the box, and most breaches trace back to a setting nobody changed. The recurring offenders are pods running as root, containers with privileged: true, host namespaces and host paths mounted into workloads, and missing network policies that let every pod talk to every other pod.
The baseline fix is Pod Security Standards. Enforce the restricted profile at the namespace level so the API server rejects privileged and root-running pods automatically:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
For anything beyond the built-in profiles, an admission controller enforces custom rules cluster-wide. Our guide on the k8s admission controller covers how to make these policies mandatory rather than advisory.
Risk 2: Over-permissive RBAC
Role-Based Access Control is how Kubernetes decides who can do what, and it is routinely too loose. The classic mistakes are binding cluster-admin to service accounts for convenience, using wildcard verbs and resources in roles, and granting secrets read access broadly. A service account with excessive permissions is a direct path from a compromised pod to the whole cluster.
Audit for the dangerous grants:
kubectl get clusterrolebindings -o json \
| jq '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'
Then apply least privilege: scope roles to specific namespaces, name explicit verbs and resources instead of wildcards, and give each workload its own service account with only the permissions it needs. Disable automounting of the default service account token on pods that do not call the API:
spec:
automountServiceAccountToken: false
That single field removes a token an attacker would otherwise find sitting inside every pod.
Risk 3: Exposed control-plane and etcd
The API server and etcd are the crown jewels. etcd stores every secret in the cluster, and by default those secrets are only base64-encoded, not encrypted. An attacker who reads etcd reads all your secrets in plaintext.
Two fixes are non-negotiable. Enable encryption at rest for secrets with an EncryptionConfiguration so etcd stores ciphertext, and lock down network access so etcd and the API server are never reachable from the public internet or from untrusted pods. Managed control planes handle much of this, but you still own the network exposure and the RBAC on top.
Check whether your API server is anonymously accessible, because an open, unauthenticated API server is a full cluster takeover waiting to happen. This same lesson applies to any datastore you run alongside the cluster: an unauthenticated database or search node bound to 0.0.0.0 is the cloud-native equivalent of leaving the front door open.
Risk 4: Vulnerable and untrusted images
Every container you run is third-party code plus your own, and both age into vulnerability. The risks here are pulling images with known critical CVEs, running images from untrusted registries, and using latest tags so you cannot even tell what shipped.
The defenses layer together:
- Scan images in CI and gate merges on critical findings. A build scan is the cheapest place to catch a vulnerable dependency.
- Continuously rescan running workloads, because CVEs are disclosed against packages that were clean when you built. Our note on container runtime scanning covers the running-workload side.
- Require signed images from trusted registries via admission control, so a tampered image cannot be scheduled.
- Track the full dependency tree, not just the top-level image. A vulnerable transitive library is easy to miss; an SCA tool makes it visible.
Risk 5: Flat networking and secrets sprawl
By default, every pod can reach every other pod. That flat network means one compromised workload can scan and pivot across the whole cluster. Apply NetworkPolicy resources to segment traffic, starting with a default-deny posture per namespace and opening only the flows you need:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes: ["Ingress"]
Secrets are the other sprawl problem. Beyond encrypting etcd, avoid injecting secrets as environment variables where you can, because they leak into logs and crash dumps, and prefer mounted files or an external secrets manager. Rotate credentials on a schedule and never bake them into images.
How to prioritize
You cannot fix everything at once, so sequence by blast radius:
- Lock down the control plane and etcd. A compromise here is total.
- Fix
cluster-adminand wildcard RBAC. This is the most common escalation path. - Enforce Pod Security Standards and block privileged pods.
- Scan images and gate on critical CVEs, then add runtime rescanning.
- Segment the network with default-deny policies.
Measuring your cluster against the CIS Kubernetes Benchmark with a tool like kube-bench gives you a concrete, scored starting point rather than a vague sense that something might be wrong. Run it once to get your baseline, then track the score as you work through the list.
FAQ
What is the most common Kubernetes security risk?
Misconfiguration. Pods running as root or privileged, missing network policies, and over-permissive RBAC cause far more real incidents than novel exploits. Enforcing Pod Security Standards and least-privilege RBAC addresses most of it.
Are Kubernetes secrets encrypted by default?
No. By default they are only base64-encoded in etcd, which is not encryption. Enable encryption at rest with an EncryptionConfiguration and restrict network access to etcd so the stored secrets are protected.
How do I fix over-permissive RBAC?
Audit for cluster-admin bindings and wildcard roles, then scope roles to namespaces with explicit verbs and resources. Give each workload its own service account and disable token automounting on pods that do not call the API.
Do I need to scan images if I use a trusted base image?
Yes. Trusted base images still accumulate CVEs over time, and your own dependencies add more. Scan in CI, gate on critical findings, and rescan running workloads because new vulnerabilities are disclosed after you ship.