Securing Kubernetes workloads in Amazon EKS (KUB315)
Securing Kubernetes Workloads in Amazon EKS
Shared Responsibility Model
AWS is responsible for the security of the cloud, including the Kubernetes clusters' control plane, underlying infrastructure, and foundational services.
Customers are responsible for the security in the cloud, including the security of their EC2 instances, worker nodes, and Kubernetes applications.
Cluster-Level Security Controls
Cluster Access Management
Unifies the APIs for managing cluster access, simplifying the configuration and providing granular control over permissions.
Allows revoking of permissions granted automatically to the IAM principal that creates the cluster.
Recommended over the older AWS-AUTH config map approach.
IAM Roles for Service Accounts (IRSA) and Pod Identity
IRSA enables granting granular AWS permissions to Kubernetes pods.
Pod Identity simplifies the trust setup, allows reuse of policies and roles across clusters, and supports attribute-based access control.
Both IRSA and Pod Identity are supported, with Pod Identity being the preferred option for EKS managed clusters.
Monitoring and Alerting
Cluster-level requests are logged in the control plane audit log, available in CloudWatch.
EKS API requests are logged in CloudTrail, allowing analysis with CloudTrail Insights.
Amazon Detective can be used to analyze and visualize VPC flow logs.
Encryption
AWS managed keys or customer-managed keys can be used to encrypt at-rest storage (EBS, EFS, FSx) and Kubernetes Secrets.
Other Controls
Kubernetes cluster endpoint can be configured to be private.
EKS APIs can be accessed through AWS PrivateLink.
Use managed components like EKS add-ons and EKS-optimized AMIs when possible.
Leverage Security Hub for predefined security checks on the cluster.
Infrastructure-Level Security Controls
EKS Auto Mode
Automatically manages the infrastructure (EC2 instances) based on the Kubernetes pod requirements, simplifying cluster management.
Reduces operational overhead and improves performance and availability.
Cluster Network Security
Kubernetes Network Policies can be used to control pod-to-pod communication.
Security groups can be applied to Kubernetes pods to control network access.
Amazon GuardDuty Integration
Integrates with the Kubernetes audit log to detect anomalies and misconfigurations.
Provides runtime protection by deploying an agent-based solution on the worker nodes.
Other Recommendations
Use AWS Systems Manager (SSM) for secure access to instances instead of open SSH.
Use container-optimized OS like Amazon EKS-optimized AMIs or Bottlerocket.
Verify cluster configuration using the CIS benchmark.
Application-Level Security Controls
Pod Security
Use Kubernetes Pod Security Standards or policy-as-code solutions like Kyverno or Open Policy Agent Gatekeeper.
Limit the use of privileged containers, disable unnecessary service account token mounts, and restrict host path usage.
Configure containers to use a read-only file system and non-root users.
Image Security
Scan container images for vulnerabilities using Amazon ECR's native integration with Amazon Inspector.
Use ECR with AWS PrivateLink to restrict image access to within the VPC.
Kubernetes Authorization using Cedar
A new open-source prototype that provides advanced authorization capabilities beyond RBAC.
Supports attribute-based access control, denials, and more granular policies.
These cookies are used to collect information about how you interact with this website and allow us to remember you. We use this information to improve and customize your browsing experience, as well as for analytics.
If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference.