The Kubernetes security issues that lead to real incidents are almost always misconfigurations, not novel exploits: over-permissive RBAC, secrets stored in plain manifests, containers running as root, exposed API endpoints, and images nobody scanned. Kubernetes gives you a powerful set of controls, but they ship mostly open by default, and the gap between "it works" and "it is secure" is wide enough to drive an attacker through. This post covers the issues worth your attention in priority order, with concrete signals for each.
Over-permissive RBAC is the number one problem
Role-based access control is where most clusters quietly go wrong. It is tempting to grant cluster-admin to a service account to make a deployment tool "just work," and that binding then sits there forever. The result is a token that, if leaked from a compromised pod, hands an attacker the whole cluster.
Audit for wildcards. A Role or ClusterRole with verbs: ["*"] on resources: ["*"] is a red flag. So is any binding to the default service account, which pods use automatically unless you tell them otherwise. Two quick wins: set automountServiceAccountToken: false on pods that never call the API, and replace wildcard roles with the specific verbs a workload actually needs.
# a workload that does not talk to the API server
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
automountServiceAccountToken: false
containers:
- name: web
image: myapp:1.4.2
Containers running as root
By default a container process runs as root inside the container, and without user namespace remapping that root maps to real root on the node. A container escape from a root process is far more damaging than one from an unprivileged user. Enforce a non-root user with a securityContext, and back it up with a policy that rejects pods requesting privilege.
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
privileged: true and hostPID, hostNetwork, or hostPath mounts deserve special scrutiny. Each one erodes the boundary between the container and the node, and each should require an explicit, documented justification.
Secrets handled carelessly
Kubernetes Secrets are only base64-encoded, not encrypted, in their default form. Anyone who can read the Secret object or the etcd backing store can read the value. Two fixes matter: enable encryption at rest for Secrets in etcd, and stop committing secret manifests to Git. A secret checked into a repository is compromised the moment the repo is cloned, and rotating it is the only remedy.
For anything sensitive, an external secret manager with short-lived, dynamically issued credentials beats a long-lived static Secret sitting in the cluster.
Exposed API server and dashboards
A Kubernetes API server or dashboard reachable from the public internet without strong authentication is an open invitation. Historically, exposed dashboards with no auth have been the entry point for large-scale cryptomining campaigns. Keep the API server behind network controls, disable anonymous auth, and never expose the dashboard with a permissive service account. Treat any LoadBalancer service in front of a control-plane component as an incident until proven intentional.
Missing network policies
By default, every pod can talk to every other pod. Flat networking means one compromised pod can reach your database, your internal APIs, and every other workload. Kubernetes network policies let you default-deny and then allow only the flows you need. Start with a namespace-wide deny-all ingress policy and add explicit allows; the first time you write one it feels tedious, but it is the control that contains a breach instead of letting it spread laterally.
Unscanned and outdated images
A cluster is only as secure as the images running in it. Pulling :latest, running images built months ago, or deploying from a registry nobody scans reintroduces known CVEs into a hardened cluster. Pin image tags to digests, rebuild on a schedule so base-image patches land, and scan at admission so a vulnerable image cannot deploy in the first place. An SCA and image scanner in the pipeline turns this from a manual chore into a gate. For the mechanics of scanning, see our container image scanner guide.
Supply chain and admission control
The newer class of Kubernetes security issues concerns provenance: can you prove the image you are running is the one your pipeline built, and not a tampered artifact? Signed images and an admission controller that verifies signatures close that loop. Pair signature verification with policy enforcement so unsigned images, privileged pods, and images from untrusted registries are all rejected before they schedule.
A pragmatic hardening order
If you inherit a cluster and want the highest return per hour, work in this order: lock down RBAC wildcards, enforce non-root and dropped capabilities, get secrets out of Git and encrypt them at rest, confirm no control-plane component is publicly exposed, add default-deny network policies, then wire image scanning into admission. Each step reduces a distinct blast radius, and none requires re-architecting your applications.
FAQ
What is the most common Kubernetes security issue?
Over-permissive RBAC. Service accounts bound to cluster-admin or roles with wildcard verbs are the single most frequent misconfiguration, and they turn a minor pod compromise into full cluster control.
Are Kubernetes Secrets encrypted by default?
No. They are base64-encoded, which is encoding, not encryption. You must explicitly enable encryption at rest for etcd, and ideally use an external secret manager for anything sensitive.
Do I need network policies if I have a service mesh?
They complement each other. A service mesh gives you mTLS and layer-7 controls, but network policies enforce layer-3/4 isolation at the pod level and act as a backstop. Use both rather than treating one as a replacement.
How do I stop vulnerable images from being deployed?
Use an admission controller that checks scan results and signatures, and configure it to reject images that fail policy. Combine that with pipeline scanning so most issues are caught before the image ever reaches the cluster.