Full Report
The Wiz research team unpacks the security implications of the new EKS access and identity management features and recommends best practices when using them.
Analysis Summary
# Best Practices: Securing Amazon EKS Identity and Access Management Features
## Overview
These practices focus on the secure implementation and configuration of the new Amazon EKS features: EKS Cluster Access Management (Cloud-to-Cluster authentication) and EKS Pod Identity (Cluster-to-Cloud authentication), providing guidance to mitigate newly introduced security risks and adhere to the principle of least privilege.
## Key Recommendations
### Immediate Actions
1. **Audit Existing Authentication Configuration:** Immediately review the current EKS cluster authentication mode. If using `CONFIG_MAP` only, start planning the transition to `API_AND_CONFIG_MAP` or `API` mode to leverage the new native IAM controls.
2. **Review and Restrict Pod Identity Usage on Default Service Accounts (SAs):** Identify all workloads currently using the default Kubernetes Service Account, especially if EKS Pod Identity is enabled. Remove or restrict permissions granted via EKS Pod Identity from default SAs unless strictly necessary and justified.
3. **Disable Service Account Token Autodetection:** For all new and existing pod specifications where AWS credential access is **not** required, explicitly set `automountServiceAccountToken: false` to prevent unintended token exposure, mitigating potential privilege escalation if Pod Identity is implicitly active.
4. **Treat New Access Controls as High Privilege:** Immediately apply elevated scrutiny and strict change control processes to any IAM Principle granted permissions via new EKS Access Policies or Access Entries, as these represent new, potent privilege escalation avenues.
### Short-term Improvements (1-3 months)
1. **Migrate to API-Native Cluster Access Management:** Move cluster administration and user access configuration away from manual `aws-config` ConfigMap modifications toward using EKS Access Entries and Access Policies managed via the EKS API.
2. **Implement Least Privilege Access Policies (Cluster Access):** When creating new Access Entries, ensure the associated Access Policies map principals to the minimum required Kubernetes RBAC privileges. Do not rely solely on the existence of an entry; permissions must be explicitly granted via policies.
3. **Audit `eks-pod-identity-agent` Configuration:** Review the deployment configuration (DaemonSet) for the `eks-pod-identity-agent`. Scrutinize configurations such as `hostNetwork` usage and privileged execution to address known problematic settings that increase the attack surface.
4. **Enhance Monitoring and Detection Rules:** Update security monitoring (SIEM/logging pipelines) to specifically track CRUD operations and permission changes against both the EKS API (for cluster access) and the Kubernetes API (for workload authorization), covering the new identity flows.
### Long-term Strategy (3+ months)
1. **Standardize on API Authentication Mode:** Aim to fully transition EKS clusters to utilize `API` or `API_AND_CONFIG_MAP` authentication mode for cluster access management, planning for the eventual deprecation of the legacy `CONFIG_MAP`-only mechanism.
2. **Establish Granular Pod Identity Mapping:** Develop and enforce a policy that requires every workload needing AWS cloud access to possess a dedicated, non-default Service Account explicitly mapped via EKS Pod Identity to the minimum necessary IAM Role.
3. **Develop Credential Exposure Playbooks:** Create and practice incident response playbooks specifically addressing the compromise of credentials or tokens exposed via the Pod Identity flow, including mechanisms to instantaneously revoke the associated IAM Role permissions.
## Implementation Guidance
### For Small Organizations
- **Prioritize Pod Identity Simplification:** Immediately focus on replacing IRSA or insecure credential injection methods with EKS Pod Identity for better S.A. granularity, provided strict SA segregation is maintained.
- **Use Built-in Access Policies:** Leverage the predefined EKS Access Policies initially for cluster access, but rapidly define custom policies based on the Principle of Least Privilege rather than granting broad built-in roles.
### For Medium Organizations
- **Phased Migration of Access Control:** Implement a phased migration plan for existing users from ConfigMap mappings to Access Entries, using `API_AND_CONFIG_MAP` mode temporarily to allow overlapping configuration during transition.
- **Dedicated SA Strategy:** Formally document the naming conventions and access role associations for every Service Account that will utilize EKS Pod Identity to maintain clear governance.
### For Large Enterprises
- **Automate Access Provisioning:** Integrate Access Entry and Access Policy creation into Infrastructure as Code (IaC) pipelines (e.g., Terraform, CloudFormation) to ensure consistency and version control, avoiding manual configuration via the EKS console.
- **Comprehensive Audit Logging:** Ensure EKS Audit Logs are integrated into a centralized platform, specifically correlating EKS API calls (for Access Entry/Policy changes) with Kubernetes API audit events (for authorization decisions).
## Configuration Examples
| Feature | Configuration Goal | Action/Setting |
| :--- | :--- | :--- |
| **K8s Pod Spec** | Prevent automatic mounting of Service Account token for pods not needing cloud access. | `automountServiceAccountToken: false` in the Pod specification. |
| **EKS Auth Mode** | Enable API-native cluster access management while retaining legacy ConfigMap support during migration. | Set cluster authentication mode to `API_AND_CONFIG_MAP`. |
| **EKS Access Entry** | Map an AWS IAM User/Role to a cluster entry role. | Create an Access Entry referencing a specific IAM Principal ARN. |
## Compliance Alignment
- **NIST SP 800-53 (AC):** Access Control, especially AC-2 (Account Management) and AC-6 (Least Privilege). The new features provide granular controls to better satisfy least privilege requirements compared to older methods.
- **ISO 27001/27002 (A.9):** Access Control. Implementing distinct, auditable identity mappings for cloud and cluster components strengthens access management control.
- **CIS Kubernetes Benchmark:** Focus on review sections related to authentication mechanisms and authorization configuration, ensuring the new EKS API controls are documented and enforced according to organization policy.
## Common Pitfalls to Avoid
- **Assuming Default Security:** Do not assume the agent or webhook components deployed by EKS Pod Identity are inherently secure; closely investigate their configuration (e.g., network exposure, privileged settings).
- **Over-permissioning Default SAs:** Granting extensive AWS permissions directly to a Service Account that is automatically mounted across many non-critical pods, as this directly violates the principle of least privilege via the Pod Identity mechanism.
- **Ignoring New Audit Points:** Failing to update audit collection practices to include EKS service API calls related to Access Entries and Policies. These represent new security control points that must be continuously monitored.
- **Ignoring Privilege Duplication:** Creating an Access Policy that grants the same permissions already provided by a legacy ConfigMap mapping, leading to confusing, overlapping, and overly broad authorization.
## Resources
- AWS Documentation on [Amazon EKS Pod Identity](defanged_link_to_eks_pod_identity_documentation)
- AWS Documentation on [EKS Cluster Access Management](defanged_link_to_eks_access_management_documentation)
- AWS EKS Security Best Practices Guide section on IAM: [aws-eks-best-practices/security/docs/iam/](defanged_link_to_eks_best_practices_iam_guide) (Review guidance on IAM cluster access manager deprecation schedule).