- Misconfigured or overly privileged containers in Kubernetes environments can facilitate unauthorized access to sensitive AWS credentials, exposing the environment to privilege escalation and malicious activity.
- Trend™ Research identified exploit scenarios involving overprivileged containers, including packet sniffing of unencrypted HTTP traffic to access plaintext credentials and API spoofing, which uses network settings to intercept Authorization tokens and gain elevated privileges.
- The AWS shared responsibility model highlights the importance of collaboration, with the service provider ensuring infrastructure security while customers are equally responsible for managing privilege scoping within their containerized applications to maintain a secure environment.
- Trend Vision One™ Container Security allows organizations to enforce proactive security policies that detect and mitigate containers operating beyond intended privilege levels —helping prevent exploit scenarios such packet sniffing and API spoofing, while reducing the overall attack surface and minimizing security risks.
Kubernetes-based container platforms play a critical role in the cloud for orchestrating and managing containerized applications efficiently and at scale. They automate deployment, scaling, and operations, making them ideal for microservices and various workloads. Among its key benefits include cloud portability, cost efficiency through better resource utility, accelerated development cycles via automation and self-healing, and simplified management of distributed systems, all of which enable resilient and scalable applications.
Amazon Elastic Kubernetes Service (EKS) is a managed service that streamlines running Kubernetes on Amazon Web Services (AWS) and on-premises. It automates the management of the Kubernetes control plane, ensuring high availability and scalability, while seamlessly integrating with other AWS services for networking, security, and storage. This enables users to focus on deploying and managing their containerized applications.
Misconfigured or overly privileged containers pose significant security risk since they can provide attackers with unauthorized access and control over sensitive data and system resources within an environment. Implementing measures such as ensuring proper configuration and limiting container privileges to only what is necessary is crucial to maintaining a secure containerized infrastructure.
In this blog post, we will examine packet sniffing-based and API spoofing-based attack scenarios, which are used to exploit excessive privileges granted to containers. Our aim is to demonstrate how these misconfigurations can be abused to extract sensitive AWS security credentials directly from within containerized applications, highlighting a critical concern in cloud environments.
We will also show how to use Trend Vision One™ to detect and respond to excessive privileges by enforcing customizable policy settings within the Container Protection section of the Trend Vision One portal.
Amazon EKS Pod Identity is a feature introduced by AWS to simplify the process of granting AWS credentials to pods running in an EKS cluster. It offers an alternative and complementary method to IAM Roles for Service Accounts (IRSA), enabling secure access to AWS resources such as S3 buckets or DynamoDB tables from within Kubernetes applications.
Setting up Pod Identity begins with installing the eks-pod-identity-agent add-on on the Amazon EKS cluster. This agent operates as a DaemonSet in the kube-system namespace, ensuring that an instance of the agent is running on each worker node.
The agent exposes a simple API that accepts the Kubernetes service account token in the Authorization header and calls a specific AWS API action: eks-auth:AssumeRoleForPodIdentity. This API is exposed on a link-local address (169.254.170.23 for IPv4 and [fd00:ec2::23] for IPv6) on port 80.
The amazon-eks-pod-identity-webhook mutating admission controller is automatically updated to inject the AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE environment variables into pods that use a service account associated with a Pod Identity. These environment variables are recognized by the AWS SDKs.
When an application in a pod using an AWS SDK makes a request to an AWS service, the SDK automatically identifies the relevant environment variables and retrieves temporary credentials from the EKS Pod Identity agent running on the node. The agent then interacts with the eks-auth:AssumeRoleForPodIdentity API to obtain the necessary credentials for the associated IAM role.
The EKS Pod Identity agent operates on each node and exposes an API on a local IP address seemingly over unencrypted HTTP.
This presents a security risk since any pod with ‘hostNetwork: true’ settings can potentially monitor network traffic on the node, enabling the interception of any credentials being sent from the API endpoint 169.254.170.23:80. Since the AWS environment doesn’t bind these credentials to a specific asset, malicious actors can use them to gain elevated privileges within the environment.
A trivial proof-of-concept (PoC) using the standard tcpdump utility demonstrates that credentials are being transmitted in plaintext. Given that AWS credentials are not bound to a specific host, they can be used by a third party to assume elevated privileges.