What is EKS
Among the plethora of Kubernetes services that popped up through the years, Amazon Elastic Kubernetes Service (Amazon EKS) stands out. The managed service enables information technology (IT) departments to run Kubernetes on Amazon Web Services (AWS) without installing, operating, or maintaining Kubernetes control plane or nodes.
The open-source system Kubernetes simplifies containerized applications by automating their deployment and scaling. Kubernetes makes it easier for app developers to easily group applications into logical units, containerizing them so they can move as a unit and function without infusing the app or container with an operating system. This makes containerized applications sleeker and more efficient. Because of the flexibility of Kubernetes, developers can create clusters of master and worker nodes in multi-container applications. As easy as Kubernetes makes creating these containerized apps or K8s, Amazon EKS makes it even easier.
How does Amazon EKS do this? By automatically running and scaling the Kubernetes control plane across zones, it ensures high availability. The same control plane automation handles load balancing, detects and replaces bad control plane instances, and automates updating of its service.
EKS Security
What about EKS security features? It integrates many security features, providing:
- Amazon Elastic Container Registry (ECR) for container images
- Elastic Load Balancing for load distribution
- Identity access management (IAM) for authentication
- Amazon virtual private clouds (VPC) for isolation
By automatically updating the open-source Kubernetes software, you can access existing plugins and tools.
As much as AWS handles automatically, the platform’s service functions under the AWS shared responsibility model, meaning that AWS and the customer share responsibility for security and compliance.
The shared responsibility model in cloud computing as applied to AWS means that the customer handles the guest operating system management, including security patches and manual updates. The customer also handles the configuration of the EKS security group firewall.
For all of its automation, the customer must also handle creating the Kubernetes security groups^5^ – one for the virtual machines and one for the control plane load balancer. Its pod security groups provide network segmentation for workloads and top the list of best practices for EKS security. It also comes misconfigured for some security best practices, something you’ll need to address manually.
EKS Security Best Practices
Because automation does not handle all security, your EKS configuration needs manual configuration using best practices. You’ll also need to handle any misconfigurations that EKS comes with out of the box. AWS offers a free best practices guide^6^ hosted on GitHub to help with proper configuration.
The AWS guide offers chapters on security, reliability, cluster autoscaling, running windows containers, networking, and scalability. With respect to security, at a minimum, your EKS security best practices should include:
- Using IAM roles to control cluster access
- Implementing a firewall to protect each cluster
- Using SSL/TLS to encrypt cluster traffic
- Accessing cluster with a bastion host
- Connecting to clusters with virtual private networks (VPNs) to connect to your cluster
- Using a monitoring solution to detect malicious activity
AWS also provides hardeneks, an open-source Python-based command line interface (CLI), for testing the implementations of the best practices recommendations. Using a KSOC (Kubernetes Security Operations Center) can help you quickly and automatically implement and manage AWS EKS security best practices, which evolve as your use evolves. AWS assumes added responsibilities once you move past self-managed workers to managed node groups and, finally, to Fargate. AWS takes responsibility for securing your underlying instance or runtime used to run your Pods. KSOC can help with the implementation of EKS monitoring best practices and EKS pod security.
EKS Security Group For Nodes
EKS uses AWS VPC Security Groups (SGs) to control the traffic between the Kubernetes control plane and the cluster's worker nodes, as well as to control the traffic between worker nodes, other VPC resources, and external IP addresses. Essentially, the security group acts like a firewall, adding an extra layer of security. The cluster security group EKS uses lets you better control the inbound and outbound traffic by setting protocols and choosing ports for access. Provision every managed node within the Amazon EC2 Auto Scaling group.
What is a node group in Kubernetes?
The term EKS node group refers to a group or pool of nodes sharing the same configuration with regard to CPU, networking, memory, operating system, the maximum number of pods, and other specifications. Each EKS security group for nodes has a unique name within the VPC, up to 255 characters in length.
Although you can create in EKS additional security groups, the service sets a quota on the number of security groups you can create per VPC. None of them can begin with the letters “sg” and you can only use select special characters. Other rules also apply to the creation of security groups, which AWS covers in its onsite documentation.
EKS Load Balancer Security Group
Using an EKS load balancer security group enables you to choose the ports and protocols for enhanced load balancer security. The security settings let the load balancer communicate with your listener port and health check port, plus route requests.
Creating a Kubernetes service of the load balancer type, the AWS cloud provider load balancer controller automatically creates a default AWS Classic Load Balancer. You can set it to create an AWS Network Load Balancer, though. However, AWS only plans to provide critical bug fixes for this controller.
Although AWS offers best practices and prescribed rule sets^10^ for various configurations, it no longer covers the cloud provider load balancer controller. It offers recommended rules for an:
- EKS internal load balancer
- EKS internet-facing load balancer
- EKS application load balancer as a target of a network load balancer
You’ll also need to update the associated security groups using either AWS Command Line Interface (CLI) or the console.
These load balancer security groups also have prerequisites for deploying a load balancer controller, a key part of the load balancer security group. These include an existing cluster with at least one subnet. You must deploy the load balancer controller on the specific cluster on which you want to use it.
EKS AWS
By now, you understand that Amazon EKS doesn’t handle security for your K8s, although it is a managed service. You need to set up your own security manually for your managed Kubernetes clusters. EKS AWS uses the shared responsibility model, so it falls to the app developer to configure the nodes and applications you run as an EKS cluster to ensure a secure implementation.
It does help ensure high availability across multiple AWS Availability Zones by running and scaling the Kubernetes control plane. It automatically scales control plane instances based on load and will also automatically detect and replace unhealthy control plane instances. You can patch these using its automated version updates. It integrates with many AWS services for handling container images, load distribution, authentication, and isolation.
The comprehensive EKS AWS tutorial web pages offer detailed, step-by-step instructions on all relevant topics from AWS EKS security groups for pods to AWS EKS architecture. This essential EKS documentation includes instructions on how to implement EKS anywhere, a method of deploying, using, and managing K8s in your own data centers.
EKS IAM
Identity and Access Management (IAM) AWS service performs two essential functions: authentication and authorization. Authentication involves the verification of identity, whereas authorization governs the actions that can be performed by AWS resources. With the app developer or manager EKS IAM role with IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied.
EKS IAM lets you use AWS JSON policies to specify access and the JSON Action element to allow or deny access. These EKS IAM actions typically use the same name as the associated AWS API operation. EKS IAM permissions include permission-only actions without a matching API operation. Some dependent actions require multiple actions in a policy to trigger access.
Kubernetes RBAC
Regardless of your EKS IAM implementation, which only takes care of authentication, you will be on your own for authorization or role-based access control (RBAC), a key security method of regulating access to computer or network resources based on the roles of individual users within your organization.
Start with the Kubernetes RBAC tutorial and focus on its good practices. Its good practice for Kubernetes RBAC groups helps to apply the practice of least privilege, a term that refers to assigning minimal RBAC rights to users and service accounts. Each account only receives permission access to what it absolutely requires in the app cluster.
Among the Kubernetes RBAC examples offered, one is to, “avoid adding users to the system:masters group.” Belonging to that group lets the account bypass all RBAC and that endangers the safety of all of your clusters. Every account should have the least amount of access and rights to clusters and nodes as possible.
Getting Help with K8s and RBAC
Built by leading experts, KSOC offers many useful features that help you manage the security challenges of adopting and running Kubernetes. We can do a gap assessment of your EKS environment as well as help with the trickier issues of understanding your gaps with RBAC. Most importantly, we are the only company that can do this in real-time. No interval scanning, only accurate information in real-time. To see real-time Kubernetes security, request a demo.