SUSE Security Admission Controller vs OPA Gatekeeper

Both OPA Gatekeeper and Kubernetes can write validation and mutation policies.

These policies can target any kind of Kubernetes resource, including Custom Resources.

You write OPA Gatekeeper policies using Rego. Rego is a query language created by the Open Policy Agent project.

You can write Admission Controller policies using different paradigms. Policy authors can use both traditional programming languages (like Go, Rust and others) or Domain Specific Languages like Rego and CEL. In Admission Controller’s you write validating and mutating policies the same way.

Sometimes a policy needs data about the current state of the cluster to make a validation or mutation decision. For example, a policy validating Ingress resources might need to know other Ingress resources already defined in the cluster to ensure no clashes happen. Admission Controller calls these policies "context aware".

Both OPA Gatekeeper and Admission Controller support these types of policies.

When deploying OPA Gatekeeper, a Kubernetes administrator decides which type of cluster data to make available to the policies at evaluation time.

It’s important to highlight how this data is then accessible by all the policies deployed.

For example, if an OPA Gatekeeper policy requires access to Kubernetes Secrets, all the other policies deployed are able to read this data as well.

Conversely, Admission Controller provides a granular access to cluster resources. Each policy has access only to the resources that the Kubernetes administrator specifies. Attempting to read unauthorized data is immediately blocked and reported to the cluster administrators.

OPA Gatekeeper has a cluster wide Custom Resource, permitting policy definition, and how and where to enforce them.

Admission Controller has two different types of Custom Resources used to declare policies. One works at the Cluster level, the other is namespaced. The name of the namespaced Custom Resource is AdmissionPolicy.

Policies deployed via a AdmissionPolicy resource affect only the resources created within the namespace they belong to. Because of that, you can allow non-administration Kubernetes users to have the RBAC privileges necessary to manage AdmissionPolicy resources, in the namespaces they can access.

This allows Kubernetes administrators to delegate policy-related work.

OPA Gatekeeper and Admission Controller policies have policy source code (Rego for OPA Gatekeeper, CEL for Admission Controller) in the Custom Resource defining a policy in Kubernetes.

Also, Admission Controller policies can have the source code of the policy managed like container images (for Rego, Go, Rust, …​). Once built, they’re pushed into container registries as OCI artifacts.

You can sign and verify Admission Controller policies using container image tools like cosign, from the Sigstore project.

You can distribute Admission Controller policies among geographically distributed container registries using the traditional tools and processes adopted for container images.

Both OPA Gatekeeper and Admission Controller are managed using GitOps methodologies.

However, for OPA Gatekeeper, there’s a coupling between the policy’s Rego code and the Custom Resource used to deploy it in Kubernetes. This introduces extra steps in CI/CD pipelines.

Rego has testing tools allowing the creation of unit test suites. Writing tests and executing them in a CI/CD pipeline is essential to ensure policies behave as expected.

To use these testing tools, the source code of the policy must be available in dedicated text files. It’s impossible to read the source code from the YAML files used to declare the OPA Gatekeeper policy. The CI/CD pipeline must synchronize the Rego source code to test with the code defined in the OPA Gatekeeper Custom Resource. You can do this using third party tools.

Admission Controller policies have CI/CD pipelines like traditional microservices. Usually their source code lives in a Git repository and then, using traditional CI/CD systems, unit tests run against it. You write unit tests using the testing frameworks of the language used to write the policy. Once all the tests pass, you compile the policy to WebAssembly and push it to a container registry. This kind of pipeline is usually maintained by the policy author.

Kubernetes administrators typically maintain other automation pipelines that react to new releases of the policy (using automation tools like Dependabot, Renovate bot, updatecli and others), or to changes to the policy configuration.

The pipeline tests the policy against different types of requests. You can do the testing using the kwctl CLI tool, without requiring a running Kubernetes cluster. The kwctl CLI tool uses the same evaluation engine used by the Admission Controller stack deployed in a Kubernetes cluster.

Both OPA Gatekeeper and Admission Controller can deploy policies using two different operation modes:

The same server evaluates all the OPA Gatekeeper policies. Conversely, Admission Controller allows definition of multiple evaluation servers. You define these servers by a Custom Resource called PolicyServer.

When declaring a Admission Controller policy, the Kubernetes administrator decides which PolicyServer host it.

This allows interesting scenarios like the following ones:

As policies are added, removed, and reconfigured the resources already in the cluster might become non-compliant.

Both OPA Gatekeeper and Admission Controller have a scanner that operates in the background. This scanner evaluates resources already defined in the cluster and flags non-compliant ones.

The only difference between OPA Gatekeeper and Admission Controller is how the scanner results get saved.

OPA Gatekeeper adds the violation details to the status field of a given Constraint Custom Resource (see here).

Admission Controller instead stores the results inside of a set of the Policy Report Custom Resources defined by the Policy Report working group.