Detailed Technical Analysis of "Privilege Escalation in EKS - Security Implications of the Default Config"

Overview:
The blog post by Ian Duffy details a critical security issue within Amazon EKS (Elastic Kubernetes Service) arising from the way IAM roles and permissions are handled by default configurations. It explores how attackers can exploit these defaults to achieve privilege escalation within an EKS cluster.

Key Technical Details:

1. Understanding EKS IAM Roles:
   Amazon EKS utilizes IAM roles to control access to Kubernetes resources. When an EKS cluster is created, a default role is often attached to the node group, providing it with permissions necessary for management functionalities.

2. Node Role vs. Masters Role:

3. Node Role: This is an IAM role attached to worker nodes. By default, this role has broad permissions for interacting with AWS resources.

4. Masters Role: This role is associated with the Kubernetes control plane and has elevated privileges to manage the cluster.

5. Privilege Escalation Vector:

6. Ian highlights how the default configurations can lead to a scenario where the node role inherently possesses permissions that should ideally be restricted to the masters role.

7. An attacker who gains access to a pod running within the worker nodes can escalate privileges by exploiting these IAM permissions. For example, the security scenario, "Create/Delete Tags for EKS managed Resources," allows manipulation of resource tags, which can lead to control over cluster management tasks.

8. Exploiting the Default Configuration:

9. Pod Access: An attacker with access to any pod can query the instance metadata service (IMDS) for temporary security credentials associated with the node’s IAM role.
10. AWS API Interaction: Using these credentials, the attacker can interact with the AWS API to call privileged actions like re-attaching roles with broader permissions to the worker nodes.

11. IAM Role Hijacking: The attacker can modify the node roles to gain permissions equivalent to the masters role, thereby gaining full administrative control over the EKS cluster.

12. Real-World Scenario:

13. The practical example demonstrates how a misconfigured IAM policy, where worker nodes have unnecessary permissions, can allow an attacker to modify the aws-auth ConfigMap, which controls access to the Kubernetes API server. This could give the attacker elevated Kubernetes API access.

14. The hacker can deploy a malicious DaemonSet to ensure the compromise persists across all nodes in the cluster.

15. Mitigations:

16. Restrict permissions granted to the node IAM roles, ensuring they only have the minimum required access.
17. Implement the principle of least privilege (PoLP) for all roles and adhere to fine-grained IAM policies.
18. Regular audits of IAM roles and their attached policies to ensure no over-permissive roles are in use.
19. Make use of Kubernetes Role-Based Access Control (RBAC) to further restrict permissions within the cluster.
20. Segregate duty between different components by isolating permissions and enacting stricter control over IAM roles and policies.

Key Takeaways:

• Default Configurations Are Risky: Default EKS configurations can lead to significant security risks if not properly reviewed and adjusted.
• Pod Access Is Critical: Any pod in the cluster can serve as an entry point for privilege escalation if it’s not secured or monitored.
• IAM Role Management: Proper management and audit of IAM roles and permissions are essential for cluster security. Misconfigurations can lead to severe privilege escalations.
• Fine-Grained IAM Policies: Employing least privilege policies significantly mitigates the risk of exploitation. This involves meticulous crafting and auditing of IAM roles and permissions.
• RBAC Utilization: Leveraging Kubernetes’s RBAC for internal cluster permissions to create multiple layers of security.

Conclusion:

The blog post by Ian Duffy serves as an essential reminder for engineers and security professionals working with Amazon EKS to not rely on default configurations. It underscores the need for meticulous role and permission management, timely audits, and the principle of least privilege to prevent privilege escalation attacks.

For full details, check the original blog post here.