When people search for "Kubernetes security breach" incidents, they're usually expecting stories about sophisticated exploitation of a Kubernetes zero-day. The more common reality is less dramatic and more preventable: exposed dashboards with no authentication, overly permissive RBAC policies, and default configurations left unchanged in production.
What Was the Tesla Kubernetes Incident?
One of the more widely cited real-world cases involved Tesla in 2018, reported by the security firm RedLock. An internally used Kubernetes administration console was left accessible without password protection, and attackers found it, gained access to the cluster's credentials, and used the compute resources to run cryptocurrency mining software. The incident also reportedly exposed some non-public data accessible from within the cluster's environment.
The technical root cause wasn't a Kubernetes vulnerability at all — it was an exposed, unauthenticated administrative interface, a configuration mistake rather than a flaw in Kubernetes itself. That distinction is the recurring theme across most publicly documented Kubernetes-related breaches: the orchestration platform worked exactly as configured, and the configuration was the problem.
What Role Does RBAC Misconfiguration Play in These Incidents?
Kubernetes Role-Based Access Control is powerful but easy to misconfigure, and overly broad permissions are a recurring factor in incident write-ups across the industry. Common patterns include service accounts granted cluster-admin privileges when a narrowly scoped role would suffice, default service account tokens automatically mounted into pods that don't need API server access at all, and RBAC bindings that grant permissions at the cluster level when namespace-level scoping would have contained a compromise significantly.
The practical consequence is that a vulnerability in a single containerized application — something as simple as a compromised dependency or an exploitable web app flaw — can escalate into full cluster compromise if the compromised pod's service account happens to carry excessive API permissions.
What About Actual Kubernetes Software Vulnerabilities?
Kubernetes itself has had legitimate CVEs over the years, including a notable 2018 privilege escalation vulnerability (CVE-2018-1002105) that allowed specially crafted requests to establish a connection through the Kubernetes API server to a backend, potentially bypassing authentication for certain requests. This was patched quickly after disclosure, and it's a useful reminder that keeping the Kubernetes control plane version current matters just as much as workload-level hardening.
That said, across the incidents that get discussed publicly as "breaches," misconfiguration and exposure — not exploitation of an unpatched core Kubernetes CVE — is the more common root cause by a wide margin.
What Actually Prevents These Incidents From Recurring?
A short list covers most of the recurring root causes: never expose the Kubernetes dashboard or API server directly to the internet without strong authentication and network restriction; apply least-privilege RBAC deliberately, auditing service account permissions rather than defaulting to broad roles for convenience; disable automatic service account token mounting for pods that don't need API server access; keep the control plane and node components on a current, patched version; and use network policies to restrict pod-to-pod traffic so a single compromised container can't freely reach the rest of the cluster.
Container image scanning and Kubernetes configuration scanning both play a role here, but they cover different layers — image scanning catches known vulnerabilities in what's running inside a container, while configuration scanning catches the RBAC and exposure mistakes that turn a contained compromise into a cluster-wide one. Our SAST/DAST product page and SCA product page both intersect with container security posture, covering the application and dependency layers that ultimately run on top of a Kubernetes cluster.
FAQ
Was the Tesla Kubernetes incident caused by a Kubernetes vulnerability?
No — it was caused by an exposed administrative console left without authentication, a configuration issue rather than a flaw in Kubernetes software itself.
What is the most common root cause of Kubernetes-related breaches?
Misconfiguration — exposed dashboards or APIs, overly permissive RBAC, and default settings left unchanged in production — appears far more often in documented incidents than exploitation of an unpatched Kubernetes core vulnerability.
Does keeping Kubernetes updated prevent all these incidents?
It addresses one risk category (unpatched core vulnerabilities) but not the more common one (configuration and exposure mistakes), so patching alone isn't sufficient without also addressing RBAC and network exposure.
What's a quick first check for RBAC exposure in an existing cluster?
Audit which service accounts and role bindings have cluster-admin or wildcard permissions, and confirm none of them are attached to workloads that don't genuinely require that level of access.