Achieving Kubernetes best practices with CIS Benchmark for Amazon EKS

By: Ankita Bhargava, Product Manager

Abstract architectural photo shot from the ground. Features a lot of modern windows and steel.Organizations are rapidly adopting cloud-native technologies like containers and Kubernetes to accelerate innovation and business growth. However, with this mass migration to the cloud comes more complex risk. As a result, businesses must simultaneously rethink their cloud security strategy and invest in new security tooling to effectively manage these new threats. Failure to do so can have severe consequences, including cloud data breaches or the inability to keep pace with competition. 

Introducing the CIS Benchmark for Amazon EKS

To help organizations avoid a potentially catastrophic Kubernetes-related security event, while enabling DevOps to work at full speed, Lacework® is introducing the CIS Amazon Elastic Kubernetes Service (EKS) Benchmark for managed Kubernetes clusters. With this capability, organizations can assess the security posture of their EKS environment to continuously find and fix risky configurations — at both build and runtime. They can also dramatically shrink their Kubernetes attack surface prior to deployment and continuously monitor their security posture for drift or unauthorized changes.

With the CIS Benchmark for Amazon EKS, customers can harden the configuration of worker nodes, Kubernetes resources (workloads, RBAC) and policies, and the cloud configuration of EKS and associated services. Why is this important? Because Kubernetes is highly customizable, with a variety of configuration options that can affect an application’s security posture. As a result, it’s no surprise that an overwhelming majority (46%) of those polled in Red Hat’s 2022 State of Kubernetes security report called out misconfigurations as their top Kubernetes security concern. 

With Lacework, customers will also be able to compare the configuration of clusters across teams, regions, and accounts within a single view. New EKS clusters are discovered automatically to ensure full visibility and coverage. Lacework also keeps track of every single resource configuration for 90 days, allowing customers to monitor how workloads, RBAC, and other Kubernetes assets change over time.

Best practices for Kubernetes security

Using the CIS Benchmark to baseline Amazon EKS security posture helps organizations achieve a number of best practices for securing Kubernetes, including the following:

Enforce the principle of least privilege:

  • Restrict access of service account tokens for the Kubernetes API, or credentials used by workloads in a cluster.
  • Restrict the use of wildcard rights in Roles and ClusterRoles.
  • Avoid attackers from breaking out of containers and accessing hosts by restricting containers from running as root, or with elevated privileges.

Restrict pod and cluster networking:

  • Prevent bad actors from bridging from one compromised pod to another by ensuring every namespace has a network policy, to isolate traffic in a cluster.
  • Force bad actors to obtain local network access before attempting to compromise the underlying Kubernetes hosts by disabling public IP addresses.

Protect secrets:

  • Prevent secrets from being exposed via application logs by limiting the use of environment variable secrets.
  • Protect data at the application layer, even if bad actors breach etc, by ensuring secrets are encrypted with customer managed keys.

 Harden Kubelet communication with API server:

  • Prevent malicious behavior by not allowing kubelets to accept unauthorized requests.
  • Avoid possible man-in-the-middle attacks by requiring the API server to authenticate kubelets before submitting requests.
  • Prevent leakage of sensitive cluster data by ensuring authentication is required for the read-only API.

 Automating configuration guardrails like CIS Benchmarks is critical to hardening Kubernetes security posture, which can prevent bad things from happening. It also supports agile development and DevOps workflows, enabling teams to innovate quickly, as their business needs require. 

Kubernetes requires a defense-in-depth approach to security

Since Kubernetes environments are incredibly dynamic with many moving parts that make them difficult to secure, the CIS Benchmark works even better when combined with further security measures.

Not surprisingly, the previously mentioned Red Hat report found that, over the last 12 months, 93% of respondents experienced at least one security incident in their K8s environments. Of these incidents, one in three contributed directly to revenue loss and customer attrition.

To safeguard against these compromises, securing Kubernetes requires a defense-in-depth approach that encompasses several complementary aspects of container and Kubernetes security. Here are three additional steps you can take to layer your security:

Scan containers for misconfigurations and vulnerabilities

As containers multiply, so does the risk and the associated attack surface. Organizations must scan containers for misconfigurations and known vulnerabilities prior to checking them into registries. In addition, organizations should ensure containers are not running as root and that operating systems, binaries, and libraries haven’t been maliciously tampered with.

However, surfacing risks within containerized applications is only part of what’s required to prevent breaches or disruptions related to the use of Kubernetes. Organizations must be able to answer who is deploying new Kubernetes workloads, who is connecting to their containers manually, what registry images are being pulled from, whether behaviors are unusual, and more.

Gain full visibility of who is doing what

Lacework automatically catalogs all Kubernetes resources and assets, giving teams full visibility into what environments look like, including where resources are. Lacework offers runtime monitoring and visibility on Kubernetes-related cloud provider activities, enabling developers and DevOps teams to rapidly find and fix misconfigurations within their infrastructure as code (IaC) — and to do so directly within developer toolchains and CI/CD pipelines.

We also ingest the Kubernetes audit logs and other key data to provide a full audit trail of all activities including the creation, deletion, and updating of resources, user activity, remote access to containers, errors in authentication and authorization, and blocks by the admission controller, amongst others. 

Additionally, since the platform uses unsupervised machine learning to understand what’s going on in Kubernetes environments, customers can quickly start benefiting from its capabilities. According to Nabil Missoum, DevSecOps Engineer at AB Tasty, “Lacework automatically learned how our [Kubernetes] infrastructure worked and started providing insights within hours.”

Detect unusual behavior fast

Finally, Lacework provides a clear visualization of what’s happening across Kubernetes workloads at runtime. By continuously monitoring for unusual behaviors, our patented Polygraph® Data Platform not only uncovers known risks, but also discovers unknown or zero-day threats as they unfold within the environment. Unlike other anomaly detection solutions, Lacework automatically learns how an organization’s specific environment and users work, and only alerts when something new happens that warrants attention. This results in teams getting only a few highly contextualized alerts on any given day, leading to faster remediation so they can focus on what matters most.

Learn more about Kubernetes security

CIS Benchmark for K8s is the latest in a line of Lacework security innovations that underscore our commitment to providing best-in-class Kubernetes security and is generally available.

To learn more about our K8s security offerings, please visit our Kubernetes web page, download our 10 security best practices for Kubernetes eBook, or read our Kubernetes solution brief.


Any unreleased products, features or functionality referenced in this blog post are not currently available and may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation or promise to deliver any product, feature or functionality, and customers should not rely on them to make purchase decisions.