blog
RSAC 2025 wrapped up in San Francisco last week. On Monday, Principal Security Engineer Eric Johnson presented a session on enabling workload identity for each managed cloud Kubernetes service: AWS EKS, Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). On Tuesday, Shaun McCullough and Eric Johnson led a hands-on learning lab focused on attacking and defending Kubernetes clusters.
The session began by comparing options for service-to-service authentication between a Kubernetes pod and the cloud provider’s API. The most common option involves using long-lived credentials, such as an AWS access key, Azure service principal client secret, or Google service account key. Embedding long-lived credentials inside a pod’s binaries or environment variables allows attackers to extract these secrets through application-level vulnerabilities, establishing long-term persistence in the victim’s cloud account. Demonstrations showed how to locate these credentials in a running pod and gain unauthorized access to cloud resources.
Next, we examined how pods can inherit their permissions from the Kubernetes node. Each pod can read short-lived tokens from the node’s instance metadata service (IMDS), making persistence more difficult. However, this option has major drawbacks. Demonstrations revealed that a Kubernetes node’s IMDS token often has excessive permissions and is shared across all the node’s pods, including any malicious pod launched by an attacker.
Finally, the session shifted focus to the third and final option: workload identity. Each cloud provider’s managed Kubernetes service (AKS, EKS, and GKE) includes OpenID Connect integration capable of signing unique identity tokens for each pod in the cluster. Attendees learned how to enable the cluster’s OIDC option and assign a Kubernetes service account to the containers running in a pod. Demonstrations showed how a pod receives an identity token and how that token can be used to securely access cloud resources.
This demonstration-driven session illustrated how each managed Kubernetes service injects signed tokens into a pod, where the identity tokens are located, and how to use the tokens to access cloud provider resources. Attendees left with an understanding of best practices for assigning a Kubernetes service account to a workload and ensuring the service account has minimal permissions to access cloud services.
Key takeaways from the session include:
Download the session slides to see how we implemented the workload identity federation solution for AWS EKS, Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). Then, clone the Nymeria Workshop GitHub Repository to practice deploying the workload identity federation solution in your own environment.
Microsoft’s Threat Matrix for Kubernetes helps organizations understand the attack surface introduced by a Kubernetes deployment. The matrix covers over 40 different attacker techniques, which ultimately helps defenders apply native Kubernetes security controls to mitigate each attack.
This learning lab starts with an introduction to Microsoft’s Threat Matrix for Kubernetes and a real world attack scenario. The attack scenario involves stolen cloud credentials granting access to an Elastic Kubernetes Cluster (EKS) running in AWS. Each attendee will be given stolen cloud credentials to connect to their Kubernetes cluster, enumerate the namespaces, and find pods running inside the cluster. From there, we explore two different Kubernetes threats.
The first threat exploits a hostPath mount privilege escalation technique. Attendees will use their stolen cloud credentials to escape to the underlying Kubernetes node. With direct access to the node’s file system, we exfiltrate sensitive data from a volume mounted to the file system.
The second threat discovers the pod permissions inherited from the Kubernetes node. Using the node’s instance metadata service (IMDS), attendees will exfiltrate privileged credentials. With the node’s credentials, we move laterally into a different cloud account and gain unauthorized access to sensitive data.
At the halfway point, the learning lab halts for an incident post-mortem. We identify the weaknesses and misconfigurations that led to the breach. Then, focus on two Kubernetes security controls that can prevent each threat.
We start by learning how Kubernetes admission controllers enable administrators to create “policy as code” guardrails. Attendees will install a Gatekeeper admission controller constraint that prevents a pod using the hostPath mount from deploying inside the cluster.
Then, we look at how Kubernetes network policies enable administrators to create “firewall rules as code” guardrails. Attendees will write a Calico network policy that prevents pods from communicating with the node’s instance metadata service.
Download the session slides to see the attack paths and defense designs.
CLS M01 Securing Cloud Access With Kubernetes Workload Identity Slides
LAB1 T09 Attacking and Defending Kubernetes: Privilege Escalation and Lateral Movement
Would you like to learn more about Kubernetes and cloud identity? Contact us today: sales [at] pumasecurity [dot] com.
Eric Johnson’s experience includes performing cloud security architecture and design, cloud native and Kubernetes assessments, infrastructure as code automation, application security automation, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments.
