OPA Alternative: A Stepped Approach to Kubernetes Policy Enforcement

Recently we’ve had a number of conversations around Open Policy Agent (OPA) where Kubernetes users are intrigued and want to use it, but are attempting to figure out the best initial policies and whether there is an easier way that doesn’t require writing Rego. To help out, here we discuss more about OPA and an alternative open source project that can help as you journey towards Kubernetes policy enforcement.

OPA Background

Open Policy Agent (OPA) is an open source, general-purpose policy engine that unifies policy enforcement across the stack. It provides a high-level declarative language that allows you to specify policy as code and use simple APIs to offload policy decision-making from your software. OPA enables you to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. You can read more in the OPA documentation.

As explained by one of its founders “OPA gives policy its own lifecycle and toolsets, so policy can be managed separately from the underlying systems that the policy applies to...OPA provides local enforcement for the sake of higher availability, better performance, greater flexibility, and more expressiveness than hard-coded service logic or ad-hoc domain-specific languages.”

Benefits of OPA

OPA allows users to set policies across infrastructure and applications. Some examples include defining:

Which users can access which resources.
Which subnets egress traffic is allowed to.
Which clusters a workload must be deployed to.
Which registries binaries can be downloaded from.
Which OS capabilities a container can execute with.
Which times of day the system can be accessed at.

OPA is also context aware so administrators can make policy decisions based on what’s happening - current outages, new vulnerabilities released, etc.

Stepped Approach to Policy Enforcement

OPA offers a lot of benefits, but it can be heavyweight so some users may need to ease into policy enforcement. As a stepped approach to Kubernetes policy enforcement, we use Polaris, an open source project. Version 1.0 was released earlier this year and the project is maturing and used across several products including Insights and Starboard.

Polaris identifies Kubernetes deployment misconfigurations by running over a dozen different checks to help users discover Kubernetes configurations that frequently cause security exposures, outages, scaling limitations, and more.

Some example checks Polaris looks out for includes:

Whether a readiness or liveness probe is configured for a pod
When an image tag is either not specified orlatest.
WhenhostNetworkorhostpathattribute is configured.
Whenresources.requests.cpu,resources.requests.memory, resources.limits.cpuorresources.limits.memoryattributes are not configured.
WhensecurityContext.privilegedis true or whensecurityContext.readOnlyRootFilesystemis not true (amongst a number of other security configuration checks)

Polaris allows you to check for common misconfigurations without the requirement to build your own policies. If you do want to add your own custom policies and checks, you can write your own using the simple JSON Schema based syntax. It’s a good place to start when you know you need policy enforcement, but don’t need all of the flexibility that OPA has to offer.

Polaris can run in three different modes:

As a dashboard, so you can audit what's running inside your cluster.
As a validating webhook, so you can automatically reject workloads that don't adhere to your organization's policies.
As a command-line tool, so you can test local YAML files, e.g. as part of a CI/CD process.

You can check out the quick start on GitHub.

At Fairwinds, we are working to make it easier to leverage OPA through Fairwinds Insights. Fairwinds Insights is available to use for free. You can sign up here.