Recent findings have unveiled significant security vulnerabilities within Amazon Elastic Kubernetes Service (EKS), allowing overprivileged containers to access sensitive AWS credentials through packet sniffing and API spoofing attacks. These issues underscore the importance of stringent container configurations and adherence to the AWS shared responsibility model.
Understanding the Vulnerability
Amazon EKS Pod Identity is a feature designed to simplify AWS credential management for pods within EKS clusters. It operates via the `eks-pod-identity-agent` add-on, which runs as a DaemonSet in the `kube-system` namespace. This agent exposes an API on the link-local address `169.254.170.23` for IPv4 and `[fd00:ec2::23]` for IPv6 on port 80. Applications use this setup to obtain temporary AWS credentials by sending Kubernetes service account tokens in the Authorization header to the agent, which then calls the `eks-auth:AssumeRoleForPodIdentity` API action.
Researchers have identified two primary attack vectors that exploit excessive container privileges:
1. Packet Sniffing: Containers configured with `hostNetwork: true` can monitor network traffic and intercept credentials transmitted in plaintext from the API endpoint `169.254.170.23:80`. Using standard utilities like `tcpdump`, attackers can capture these credentials, leading to unauthorized access and potential privilege escalation.
2. API Spoofing: Even if the `CAP_NET_RAW` capability is removed, containers with `CAP_NET_ADMIN` privileges can manipulate Network Interface Card (NIC) settings. By disabling the `eks-pod-identity-agent` HTTP daemon and deploying a malicious HTTP server on `169.254.170.23:80`, attackers can intercept Authorization tokens. This method allows them to assume roles and gain elevated privileges within the AWS environment.
AWS’s Position and the Shared Responsibility Model
Upon reporting these vulnerabilities, AWS determined that the behavior aligns with expected functionality within the node’s trust boundary. According to AWS’s shared responsibility model, customers are responsible for securing their applications and data. AWS emphasizes that while they manage the security of the cloud infrastructure, customers must ensure the security of their configurations and applications running in the cloud.
Mitigation Strategies
To protect against these vulnerabilities, organizations should implement the following measures:
– Apply the Principle of Least Privilege: Ensure that containers operate with only the necessary permissions. Avoid granting excessive capabilities such as `CAP_NET_RAW` and `CAP_NET_ADMIN`, and refrain from using `hostNetwork: true` unless absolutely necessary.
– Regular Security Audits: Conduct routine audits to identify and address potential vulnerabilities within EKS clusters. This includes assessing configurations and access controls to ensure they adhere to security best practices.
– Implement Network Policies: Define and enforce network policies to control traffic between pods and restrict unauthorized access to sensitive endpoints.
– Monitor and Log Activities: Utilize monitoring tools to detect unusual activities and maintain logs for auditing purposes. This helps in identifying and responding to potential security incidents promptly.
– Use Security Solutions: Deploy security solutions that can detect and block containers operating with elevated privileges. For instance, Trend Vision One Container Security can identify and mitigate risks associated with overprivileged containers.
Broader Implications and Best Practices
These vulnerabilities highlight the critical need for robust security practices in managing containerized applications within cloud environments. Organizations should consider the following best practices:
– Restrict Access to the Kubernetes API: Limit access to the Kubernetes API to authorized personnel only. Utilize AWS PrivateLink for private cluster endpoint access to ensure that traffic remains within your Virtual Private Cloud (VPC), reducing exposure to potential attacks.
– Regularly Update EKS Clusters and Worker Nodes: Keep EKS clusters and worker nodes updated to the latest secure versions to mitigate vulnerabilities. While EKS handles upgrades automatically, it’s essential to manually request upgrades and ensure compatibility with your configurations and workloads.
– Use AWS Secrets Manager or AWS KMS: Securely store and manage secrets such as API keys and passwords using AWS Secrets Manager or AWS Key Management Service (KMS). These services provide automated rotation of secrets, minimizing the impact of potential compromises.
– Implement Continuous Monitoring: Utilize monitoring tools like Amazon CloudWatch Logs and AWS CloudTrail to monitor user activities and API usage. These tools provide real-time insights and support automation, enabling prompt responses to security incidents.
– Employ Threat Detection Services: Integrate threat detection services like Amazon GuardDuty to continuously monitor your EKS environment for potential threats. GuardDuty uses machine learning and anomaly detection to identify and prioritize threats.
– Conduct Regular Image Scanning: Before deploying applications, scan container images for vulnerabilities using tools like Amazon ECR image scanning. This practice helps identify and fix vulnerabilities before they can be exploited.
Conclusion
The discovery of these vulnerabilities in Amazon EKS serves as a crucial reminder of the importance of adhering to security best practices and the AWS shared responsibility model. By implementing stringent container configurations, conducting regular audits, and utilizing AWS security services, organizations can mitigate risks and ensure the security of their cloud environments.
