AWS made its Elastic Container Services for Kubernetes (EKS) generally available today. We at Aqua had access to the preview version for some time, which allowed us to ensure that our container security platform works with EKS to provide its full spectrum of runtime protection capabilities.
The integration of Aqua with EKS provides a seamless way to enforce compliance and security policies on applications running on EKS clusters: Preventing unapproved images from being deployed, enforcing runtime policy controls on containers and pods, ensuring that the cluster nodes are properly configured against the CIS Kubernetes benchmark, and more.
Here’s a quick rundown of what using securing Kubernetes clusters on Amazon EKS looks like.
What is Amazon EKS? How is is different from “bring your own” Kubernetes?
EKS is a managed Kubernetes service. It’s completely based on upstream Kubernetes, so it should be familiar to anyone already using Kubernetes. It provides transparent integration with other AWS services like IAM, and also removes much of the hassle of setting up your own K8s cluster, configuring it properly, etc.
From a security standpoint, the main difference is that as a managed service, the K8s cluster is managed by AWS. The user doesn’t manage the master node, only worker nodes, which impacts how you would implement security controls.
Deploying Aqua on EKS
As a first step, we deploy the Aqua containers on an EKS cluster. Typically we do this using a daemonset. Below you can see how the Aqua services are deployed alongside application and system services:
Looking inside a node, we see how they are deployed as pods:
In the Aqua Command Center, we can see all the deployed containers as they’re deployed on the node, and their statuses:
Additionally, in the Enforcers screen, we can see that Aqua Enforcers have been deployed on the cluster, and on 3 worker nodes:
Preventing Unapproved Images from Running
Aqua uses Image Assurance policies to determine whether images will be allowed to run – which the Aqua Enforcer enforces.
In this instance, we created a CVSS score threshold, so an image containing any known vulnerabilities whose score exceeds this threshold will be disallowed:
Unfortunately, in this instance we used an older Redis image that has many vulnerabilities, including high severity ones that score above 6, so it is listed as disallowed::
As EKS tries to run the vulnerable Redis image, it is blocked by the Aqua Enforcer:
Blocking Unauthorized Changes in Runtime
Another cool feature of the Aqua runtime policy that is deceptively simple to use, but has a lot of technology behind it, is what we call Drift Prevention:
Essentially, by checking these boxes you can enforce the immutability of your environment by preventing any changes to containers compared to their originating images. Aqua creates a precise cryptographic digest of the image when it’s built, and then compares the contents of each layer of the image to the container resources. Any change to those resources will be prevented.
Let’s see what happens when we try and Bump Versions of our Redis container instead of updating the image at the source:
We’ve been denied, and we can view the full details of this event in the Aqua audit screen:
So there you have it.
Securing workloads on Amazon EKS is done in an almost identical fashion to other Kubernetes deployments – a testament to how well AWS managed to keep EKS compatible with upstream Kubernetes. Great news for anyone considering the convenience it offers in running K8s clusters, and especially if you’re already running other workloads on AWS.
You can read more about how we secure the various AWS container services on our container security on AWS page.
