Amazon Elastic Kubernetes Service (Amazon EKS) is Amazon’s popular, managed Kubernetes service. It lets you use open-source Kubernetes to orchestrate containerized applications, without the need to install and administer the Kubernetes control plane and infrastructure required for Kubernetes clusters.
Kubernetes security in EKS is the responsibility of both Amazon Web Services (AWS) and the client. This shared responsibility model divides the main security aspects as follows:
AWS offers an Identity and Access Management (IAM) service that helps administrators control access to AWS resources, at no extra charge. IAM administrators control who can sign in and who has permissions to use an Amazon EKS resource, based on policies defining access for service administrators and service users.
Service administrators determine which users should have access to each EKS resource. Users are provided credentials they can use for authentication and authorization of Kubernetes resources. Service users should only have access to the features they need to do their job—if they require additional permissions, they should contact the IAM administrator.
CloudWatch logs store diagnostic and audit logs from the control plane. Each EKS control plane receives its own log group. It is important to monitor these logs to discover security issues and other production issues.
AWS CloudTrail records EKS activity, capturing all API calls made by users, roles, or AWS services, or EKS console requests.
Related content: Read our guide to Kubernetes observability
Kubernetes lets you create key/value pairs and deliver them to applications running in pods. If these key/value pairs contain sensitive data, you can use Secret Store, a Container Storage Interface (CSI) driver. The driver is implemented by solutions like AWS Secrets Manager and AWS Parameter Store.
AWS Secrets Manager provides central storage and management for Kubernetes secrets, as well as the AWS Secrets and Configuration Provider (ASCP) plugin, which lets you work with legacy Kubernetes workloads that previously received secrets through etcd. It also lets you use IAM policies to define which pods can access each secret.
AWS Regions and Availability Zones (AZs) make it possible to run resources redundantly in multiple, physically isolated data centers. This allows you to make AWS workloads fault tolerant, scalable, and highly available.
Amazon EKS operates across multiple AZs, automatically scaling the control plane to ensure high performance. EKS detects and heals malfunctioning control plane instances, and performs automated patches and updates for all control plane components. EKS guarantees a service-level agreement (SLA) uptime of 99.5% for the Kubernetes API Server.
Here are best practices that can help you improve EKS security.
AWS offers three storage options for Kubernetes: Amazon Elastic Block Storage (EBS), Amazon Elastic File Storage (EFS), and Amazon FSx for Lustre. All three provide encryption at rest using either service-managed keys or customer master keys (CMKs).
Configure Amazon Elastic Compute Cloud (Amazon EC2) nodes for EKS according to the Center for Internet Security (CIS) Kubernetes Benchmark, which provides community-approved guidance for securely configuring Kubernetes clusters and nodes. The benchmark covers control plane configuration, node security configuration, policies, and managed services. You can run the open-source tool kube-bench to test your clusters for CIS security recommendations.
Related content: Read our guide to recent Kubernetes vulnerabilities
A Kubernetes cluster allows communication between all pods by default. This flexibility may be useful for development and experimentation, but it is not considered secure. Kubernetes network policies provide a mechanism to restrict network traffic between pods (commonly referred to as east-west traffic) and between pods and external services.
Kubernetes network policies work at layers 3 and 4 of the Open Systems Interconnection (OSI) model. They use pod selectors and tags to identify source and destination pods, but can also include IP addresses, port numbers, protocol numbers, or some combination of these.
Calico is Tigera’s open-source policy engine and can be used with EKS. In addition to implementing all Kubernetes network policy features, Calico extends network policies with a richer feature set, including support for layer 7 rules (such as HTTP) with Envoy’s direct integration into Calico’s pluggable data plane.
Placing worker nodes in a private subnet reduces your threat surface, because it minimizes exposure to the public internet. In EKS, the allocation of public IP addresses to nodes in a managed node group is controlled by the subnet in which these nodes are deployed (previously, nodes in a Managed Node Group were automatically assigned public IPs). If you choose to deploy your worker nodes in public subnets, implement AWS security group rules to limit their exposure.
Calico Enterprise and Calico Cloud provide Kubernetes security, observability, and networking on Amazon EKS, as well as on Amazon EC2 for self-managed Kubernetes.
Calico Enterprise and Calico Cloud offer the following unique features for EKS security: