Workloads

With EKS Auto Mode, customers continue to maintain responsibility for their application containers, including availability, security, and monitoring. Auto Mode provides a solid foundation to build upon, but there are several areas where following EKS best practices can improve the security posture of those workloads.

Configuration

Because EKS Auto Mode nodes are Kubernetes conformant, standard Pod-level configurations work as expected. For example, the Pod securityContext field can be used to give additional permissions to Pods and volumeMounts can be used to provide access to the host filesystem. Even then, Pods however still face the restrictions provided by SELinux and a read-only root filesystem on the node. You can use Kubernetes policy enforcement tools like Kyverno or OPA Gatekeeper to limit Pod-level configuration within a cluster. Additional guidance for Pod security can be found in the EKS Best Practices guide.

To vend IAM credentials to Pods within a cluster, EKS Auto Mode nodes include built-in support for EKS Pod Identity. When a Pod is launched using a Kubernetes service account that is configured with Pod Identity, the Kubernetes control plane injects a set of environment variables into the Pod. These environment variables cause the AWS SDK to request credentials from the Pod Identity component that Auto Mode has preconfigured on the Node. This process involves the AWS SDK fetching the Pod's service account token, assigned by the Kubernetes API server, and exchanging it for IAM credentials via the eks-auth:AssumeRoleForPodIdentity API. This is the only permission on the managed AmazonEKSWorkerNodeMinimalPolicy policy.

Note

IAM roles for service accounts (IRSA) can also be configured to provide credentials to Pods, while Pod Identity remains the recommended method.

Runtime monitoring

Runtime monitoring observes and analyzes operating system level, networking, and file events to help you detect potential threats in the workloads in your environment. This can include detection of issues such as container breakouts, creation of reverse shells, or elevation of privileges.

Because EKS Auto Mode nodes are fully Kubernetes conformant, runtime monitoring systems that are compatible with Kubernetes nodes should work with Auto Mode nodes. We recommend using Amazon GuardDuty or a third-party solution that is validated to work with Auto Mode for runtime monitoring. The full list of runtime issues that GuardDuty can detect is available in GuardDuty Runtime Monitoring finding types.