Kubernetes

Kubernetes is an open-source platform for orchestrating containerized applications across clusters of machines. Often abbreviated “K8s,” it automates the deployment, scaling, and management of containers (which are lightweight, self-contained runtime environments for applications). 

In practical terms, Kubernetes allows you to run hundreds or thousands of application containers and ensure they stay running, can discover each other, and can survive machine outages. It provides abstraction in the form of Pods (the basic unit, which can contain one or more containers), Services (for networking and load-balancing), and many other resources like Deployments, ConfigMaps, Ingress controllers, etc. 

How does it affect identity security?

From an identity perspective, Kubernetes has its own role-based access control (RBAC) system and can integrate with external identity providers for authentication. Each service or component in Kubernetes can be given service accounts and permissions. Essentially, Kubernetes acts as an automated data center: you tell it what to run, and it figures out where and how, while providing mechanisms to secure and isolate workloads.

Kubernetes introduces an additional layer of identity management within a cloud or data center environment. Inside a Kubernetes cluster, you have identities like service accounts (for pods and controllers), user accounts (for humans or CI systems interacting with the cluster), and roles/ClusterRoles that define what actions each identity can perform on which resources. 

Securing a Kubernetes cluster from an identity standpoint means ensuring that these accounts and roles are properly configured with least privilege. If an attacker compromises a container in a cluster, the next thing they often attempt is to exploit that container’s service account to gain higher privileges (for example, accessing the Kubernetes API to control other pods). Thus, rotating service account tokens, limiting their scope, and disabling default overly-permissive accounts is crucial. 

Another aspect is Kubernetes API access – this should be locked down so that only authenticated, authorized users (or services) can make changes. Many high-profile Kubernetes breaches have occurred due to misconfigurations like the Kubernetes dashboard left open without a password, or privileged credentials stored in container images. 

Because Kubernetes often runs critical microservices and may have secrets (API keys, database passwords) in its configuration, compromising it can lead to a broader compromise of application identities and data. In short, Kubernetes is powerful, but if not secured, it can become a central point of failure for identity security: one mis-configured admin role could let an attacker control all your cloud workloads. So, treating Kubernetes security – especially auth and RBAC – as a first-class part of your identity security program is essential when you adopt K8s.

Case study

An eye-opening Kubernetes-related breach occurred at Tesla in 2018. Attackers managed to find an unprotected Kubernetes console belonging to Tesla – essentially a dashboard that did not require any authentication to access​. Through this open K8s console, the attackers not only were able to see Tesla’s cloud workloads, but they also discovered credentials stored within the cluster. Notably, they found AWS access keys in the Kubernetes environment (possibly in configuration files or secrets), which allowed them to access Tesla’s Amazon cloud resources.​

Using this access, the attackers diverted Tesla’s cloud compute power to run cryptocurrency mining (a breach often termed “cryptojacking”), and they also had potential access to sensitive data (telemetry information) stored in Tesla’s S3 buckets​. The breach was detected by a cloud security firm (RedLock) rather than Tesla’s internal monitoring. This incident illustrated multiple identity security failures: the Kubernetes admin interface lacked any identity verification, Kubernetes secrets (with cloud keys) were not sufficiently protected, and the cloud IAM roles allowed the Kubernetes service excessive access (or the keys were not rotated). 

‍