A Kubernetes security breach almost never starts with an exotic zero-day; it starts with an exposed dashboard, a leaked credential, or an RBAC role that hands out far more access than anyone intended. Attackers scan for these misconfigurations constantly, and clusters running with default settings are the easiest targets on the internet. Understanding how a Kubernetes security breach actually unfolds is the fastest way to prevent one.
The reassuring part is that the same handful of mistakes shows up again and again. Fix those and you eliminate the bulk of practical risk.
The Anatomy of a Real Breach
The most instructive public example is the 2018 Tesla incident reported by cloud security firm RedLock. Attackers found a Kubernetes administration console that was not password protected. Inside the dashboard, they discovered credentials for Tesla's AWS environment. They then deployed cryptomining software and deliberately kept CPU usage low and pointed the miner at an unlisted endpoint to evade the obvious detection signals.
That single incident contains most of the lessons worth learning:
- An exposed management interface gave the initial foothold.
- Secrets stored where an attacker could reach them turned a single cluster into a cloud-account compromise.
- Cryptojacking with throttled resource use shows attackers tune their behavior to slip past naive monitoring.
Tesla's actual data exposure was limited, but the pattern is exactly how larger breaches begin.
The Attack Paths That Matter
Exposed API Server and Dashboard
The Kubernetes API server is the control plane for the whole cluster. If it is reachable from the internet with anonymous or weak authentication, an attacker can list secrets, create pods, and pivot anywhere. The old Kubernetes Dashboard was a frequent culprit when deployed without authentication. Lock the API server behind network policy or a private endpoint, and never expose the dashboard publicly.
Leaked or In-Cluster Secrets
Kubernetes Secrets are only base64-encoded by default, not encrypted, unless you enable encryption at rest. A pod that can read secrets it doesn't need, or a secret baked into a container image, becomes an attacker's key ring. Cloud credentials stored this way are the classic escalation from "one compromised container" to "our entire cloud account."
Over-Permissive RBAC
Role-based access control is powerful and easy to get wrong. A ClusterRole bound to cluster-admin for a service account that only needs to read one namespace is a standing invitation. The following is the kind of binding you should be able to justify — or delete:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: too-much-power
subjects:
- kind: ServiceAccount
name: build-runner
namespace: ci
roleRef:
kind: ClusterRole
name: cluster-admin # almost never the right answer
apiGroup: rbac.authorization.k8s.io
Grant the narrowest role that lets the workload do its job, scoped to a single namespace where possible.
Vulnerable Container Images
A breach can also start inside a workload. A container running a package with a known critical CVE gives an attacker code execution in the pod, and from there they probe for the misconfigurations above. Scanning images before they run is essential; an SCA tool can flag known-vulnerable packages transitively, including the deep dependencies your base image dragged in.
Hardening a Cluster: The High-Value List
You do not need to do everything at once. These changes deliver the most protection per hour of effort:
- Enable RBAC and audit it. Remove wildcard permissions and unused bindings. Run with the API server audit log on.
- Turn on Secrets encryption at rest and integrate an external secrets manager for cloud credentials.
- Apply network policies so pods can only talk to the services they actually need — a default-deny posture contains lateral movement.
- Use Pod Security Standards (the replacement for the deprecated PodSecurityPolicy) to block privileged containers, host-namespace sharing, and root execution.
- Scan images in CI and block deployment of images with unresolved critical findings.
- Keep the control plane and nodes patched. Kubernetes and its container runtime ship security fixes regularly.
Detecting a Breach in Progress
Prevention fails eventually, so you also need eyes on the running cluster. Watch for the signals the Tesla attackers tried to hide: unexpected outbound network connections, new pods created by service accounts that never create pods, and resource usage patterns that don't match your workloads. Runtime security tools such as Falco can alert on suspicious syscalls — a shell spawned inside a container that should only run one process is a strong indicator that something is wrong.
Ship the API server audit log and container logs somewhere an attacker can't reach and can't delete. In the Tesla case, low CPU usage defeated a simple resource alert; behavioral signals like an unlisted mining endpoint would have caught it.
Where This Fits in Your Program
Kubernetes security is part of a broader supply chain and infrastructure posture. The image scanning belongs to the same discipline as scanning your application dependencies, and RBAC review belongs alongside your cloud IAM review. Teams that treat them as one program — with policy gates in CI/CD — catch the misconfigurations before they reach production rather than after an attacker does. If you are comparing tooling approaches, our pricing page outlines how scanning scales across projects.
FAQ
What is the most common cause of a Kubernetes security breach?
Misconfiguration, not software vulnerabilities. Exposed dashboards or API servers, secrets an attacker can read, and over-permissive RBAC account for the majority of real-world incidents. These are configuration choices, which means they are also the easiest class of risk to fix.
Are Kubernetes Secrets encrypted by default?
No. By default they are only base64-encoded in etcd, which is trivially reversible. You must explicitly enable encryption at rest, and for sensitive cloud credentials it is better to use an external secrets manager rather than storing them in the cluster at all.
Does scanning container images prevent a Kubernetes breach?
It prevents one important attack path — a vulnerable package giving an attacker code execution inside a pod. It does not address misconfiguration risks like exposed dashboards or bad RBAC, so image scanning is necessary but not sufficient. Combine it with configuration hardening.
What replaced PodSecurityPolicy?
PodSecurityPolicy was deprecated in Kubernetes 1.21 and removed in 1.25. Its replacement is Pod Security Standards, enforced through the built-in Pod Security Admission controller, which offers three profiles: privileged, baseline, and restricted.