Containers

Harden Amazon EKS in minutes with Styra DAS Free and OPA

In the Amazon EKS Best Practices Guide, AWS recommends Open Policy Agent (OPA) as a policy-as-code (PaC) solution for Kubernetes pod security. The long list of pros provided for PaC focuses mainly on the flexibility and comprehensive control that PaC provides when compared with built-in pod security admission. While PaC brings powerful flexibility, it can be complex to learn and requires new skills, languages, and capabilities.

The evolution of policy-as-code for Kubernetes

In just a few years, we have seen DevOps teams evolve their policy implementation from custom code, to Pod Security Policies (PSPs), to Open Policy Agent (OPA) Gatekeeper. All along, the goals have been the same—enforce guardrails with as little overhead as possible. The next step in this evolution is Styra Declarative Authorization Service (DAS) Free. It builds on OPA with a single control plane for all Kubernetes resources, significantly enhanced management and maintenance functionality, graphic user interface (GUI), and clean command line interface (CLI) implementation of all testing, monitoring, and maintenance features for those who prefer to directly evaluate policy from the terminal against local Kubernetes manifests.

With a couple of commands, Styra DAS seamlessly installs OPA in your Kubernetes cluster as both a validating and mutating admission controller. This allows you to not only validate all workloads against your custom policies but to also modify noncompliant workloads before deployment. Styra DAS Free also provides a built-in policy library of over 100 policies (including all 16 control aspects of a pod) derived from real-world use cases. Further speeding deployment and easing ongoing compliance initiatives, Styra DAS includes best practices, such as prebuilt policy packs, including MITRE ATT&CK, Center for Internet Security (CIS) Kubernetes Benchmarks, Payment Card Industry Data Security Standard (PCI DSS) 3.2, and PSPs. These curated groups of policies give DevOps teams a turnkey solution to secure their containerized workloads without spending time researching, identifying, and implementing baseline policies.

With great power…

As the creators of OPA, Styra has worked with hundreds of production Kubernetes deployments and learned that some teams don’t have the time to invest in learning a dedicated policy language, such as Rego, which was developed for maximum flexibility. However, every app and development team needs comprehensive control over Kubernetes deployments, regardless of how much time they have to spend on writing and managing custom policy. This is the reason behind the development of Styra DAS Free.

Styra DAS Free is a control plane for OPA, which was purpose-built to deploy and manage OPA policies without hassle. For Amazon EKS, this means that within 15 minutes, you can do the following:

  • Deploy autogenerated OPA instances in seconds, without any manual configuration.
  • Create custom guardrails from a prebuilt library of well over 100 policies.
  • Validate the state of any current clusters.
  • See the impact of changes before you commit them to prevent errors, outages, and rework.

So it’s fast. But what can it do in just 5 minutes? Here we’ll focus on just a few of the critical security policies called out in the Amazon EKS Best Practices Guide, all of which are built into Styra DAS Free. Each of these policies can be built, tested, implemented, and monitored right out of the box without spending any time learning OPA or Rego or doing any custom coding of admission control policies.

Deploy your first 5 security policies in just 5 minutes

Let’s look at the first five policies in terms of working from big to small. We’ll start with host protections, then container protections, and finally, process protections.

Restrict the containers that can run as privileged

Letting a container run with privilege gives that container all the power of a root Linux user and means that any compromised container can manipulate the host files as well as read and modify data for other containers. Certainly, there are reasons this might be necessary, and compensating controls will be in place to ensure privilege is hard to abuse. However, limiting privilege by default is always a best practice.

To prevent systems from running as privileged, all you have to do in Styra DAS Free is choose “Prohibit Privileged Mode” and rest assured that no container in that cluster can escalate out of control. Of course, if there are containers that do need privilege, the following screenshot demonstrates that there are built-in rules that more granularly control privileges by container type, and you can always choose to deploy any rule by annotation, namespace, or more for granularity and customization.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to deploy any rules of your choice. In this case, a rule to prohibit containers from running in privileged mode is being deployed.

Configure read-only file system

Attackers have shown that we need to do everything we can to enforce the practices of least privilege everywhere by default. Specifying a read-only file system (and controlling exceptions when needed) is another way that the Amazon EKS team and security practitioners in general have specified to prevent missteps that lead to compromise.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to deploy a read-only rule to ensure every container's root file system is read-only.

Don’t allow any containers to run as root

Kubernetes containers run as root by default, so they can change anything that needs changing within their own container. However, unless that level of power is truly necessary, the best practice is to limit what can be installed or accessed by choosing the Prohibit Running as ‘root’ policy in Styra DAS Free. This way, each container can run its intended processes and nothing more.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to deploy a Prohibit Running as 'root' rule to prevent all containers from running as 'root.'

Disallow privilege escalation

In the previous screenshot, we prevented Amazon EKS from scheduling any containers that want to run with privilege. But we also want to prevent containers from being able to escalate their privilege in order to stop attackers from doing things like finding secrets, changing role-binding, and otherwise moving around inside a system to compromise your app and data.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to deploy a Disallow privilege escalation rule to prevent attackers from accessing private information.

Set requests and limits for each container

When containers compete for resources, unpredictability is the only result. Even without a malicious actor trying to attack, an out-of-control process can result in workloads that will never be scheduled or lead to production containers being stopped. The best case is this can break your app. The worst case is the unexpected vulnerability from an unpredictable stack overflow. Avoid resource contention and denial-of-service (DoS) attacks by preventing any container from stealing all the available resources from your cluster.

Many DevOps members use limit ranges or quotas to achieve this same goal. However, with Styra DAS Free, teams get a number of advantages. Primarily, thanks to the built-in library and consistent control plane, teams get faster and easier implementation in even a single cluster and, of course, consistency of policy across clusters as well. Also, once OPA is deployed through Styra DAS Free, it is easier to roll out new policies and policy changes to a cluster than to reconfigure the cluster for limit ranges. Unlike individual rules deployed as one-offs, Styra DAS Free with OPA allows for a single-policy implementation for all guardrails across the entire software lifecycle, making policy far easier to deploy, test, manage, and maintain.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to set requests for each container. In this case, a rule to Require Resource Requests is being deployed to ensure all containers specify both CPU and memory requests.

Of course, once you mandate that each container must have request limits, you’ll also want to look into using Styra DAS Free to specify the CPU and memory limits by default as well. This can be done by preventing any unspecified workloads from being scheduled or mutating any container policy to include limits by default, even when the developer might have forgotten.

In Styra DAS Free, select the Rules option within the Validating folder in the menu sidebar. Then select the Add Rule dropdown menu to set limits for each container. In this case, a Require CPU Limits rule is being deployed to ensure all containers specify CPU limits.

Flexibility without complexity

Styra DAS Free isn’t just the fastest way to set up OPA policies. It’s also a turnkey solution for monitoring your Amazon EKS policy to ensure that OPAs are working as expected and policy is having the intended effects.

Choose whether you want to monitor policy to flag issues but not stop production or move to hard enforcement to prevent errors from ever making their way to production. Before committing any new changes, run a built-in impact analysis to compare the result of the proposed changes to the existing cluster policy to see if your change will break deployments or have the effect you intend. Styra DAS Free was developed alongside OPA by the founders of the project to provide the operational and security tools needed to ensure OPA instances are correctly running at scale throughout the development lifecycle.

In Styra DAS Free, select your cluster from the menu sidebar. In this case, Banteng cluster is selected. The Decisions section of the Dashboard shows a built-in impact analysis of Mutations and Validations and the amount of allowed requests, denied requests, advice, errors, and latency.

Better collaboration

Use Styra DAS Free to build burndown lists of compliance issues that you can work through with members of your team to better understand issues, find solutions without outages, and collaborate with security and governance teams without reading through code.

Styra DAS Free gives teams the immediate ability to choose how and where each policy is enforced by label, namespace, custom annotation, and more.

In Styra DAS Free, select your cluster in the menu sidebar. In this case, Buffalo cluster is selected. The Compliance section of the Dashboard has a burndown list of Violation issues, such as a resources on containers missing a readiness probe.

Proven in production

Styra DAS Free is the same solution that’s been proven in some of the largest Amazon EKS and Kubernetes deployments in the world, running in production at global enterprises like Capital One, the European Patent Office, and Zalando. Since the guardrail policies are built from the best practices of the OPA community, DevOps teams can trust code that’s been hardened by thousands of DevOps engineers across millions of pods and billions of policy decisions.

Styra DAS Free is available on AWS Marketplace and might just take less time to set up than it took to read to this point. So have at it! It’s free, and it’s the easiest way to get OPA PaC in place on Amazon EKS, all without having to code.

Chris Webber Headshot

Chris Webber, VP of Growth Strategy, Styra

Chris Webber is VP of Growth Strategy at Styra, where he leads the company’s product lead growth efforts. Webber is a security wonk, a cloud evangelist, a product guy, and a recovering IT professional. Having spent time at both Silicon Valley startups and global powerhouses, he developed his particular slant on cybersecurity at companies like Zscaler, Blue Coat Systems, Centrify and SafeBreach.