Compliance Operator or OPA?
by Juan Antonio Osorio Robles
As some of you might know, with OpenShift 4.6 comes the release of something we’ve been working on for some time: The Compliance Operator.
We’ve given a talk about it before in DevConf. If you’re interested in more information about the operator and even a demo, I recommend checking that out!
However, this is not what this blog post is about.
Over the time that we’ve been evangelizing the operator to other folks, we tend to get some similar questions. One that seems to concern folks a lot is:
What’s the difference between the Compliance Operator and OPA?
Sometimes this question is about Gatekeeper instead of OPA, but the theme is similar.
Here, I’d like to spell the differences between the projects, and re-assure folks that they’re not competing, but can very nicely compliment each other instead.
Policy is becoming a buzzword
One of the reasons for the aforementioned confusion is that, in the end, all of these projects deal with some sort of policy in one way or the other. However, something to take into account is that policies can mean very different things and can be actionable in different ways as well. The key thing about policies is how you act on them, and this is how the projects differ.
Compliance Operator
The OpenShift Compliance Operator came from the need to be able to evaluate and report on compliance policies in highly regulated environments. Folks have traditionally used OpenSCAP to do this, so they might have tools that can interface with it, automation in place, and even ready-made pipelines to process artifacts generated by the tool. In some cases, the usage of the tool to evaluate your deployment is required in order to get Authority To Operate, as it’s a NIST-certified tool. On the other hand, there already is a community writing rules to verify compliance as part of the ComplianceAsCode project.
So, as a project, we embedded ourselves into this community, and heavily leverage the tools that have already been created. The operator itself automates the running of OpenSCAP to check both the configuration and status of the nodes (Node checks), or the configuration of OpenShift itself (platform checks). For nodes checks, OpenSCAP will do an authoritative check of the state of the system by checking running services, installed packages, state of the rpm database, configuration files, file permissions and ownership, kernel arguments, among other things.
NOTE: Currently only OpenShift is supported… but there is no reason this is a requirement. If folks would be interested in leveraging the tool for other Kubernetes distributions, we’d be open and happy to help.
On the other hand, we’ve been quite careful in not using the word policy in the terminology introduced by the operator. This is to try to avoid the confusions that come with the word.
This is the terminology the operator uses:
- The operator verifies that a deployment meets a compliance profile.
- A profile consists of a set of rules and set values.
- Rules do the actual check and help you meet a specific requirement or security control.
- After a scan, you’ll get check results and remediations.
- Remediations help you get your cluster closer to compliance.
To translate this to policies:
- A profile is a set of configuration policies represented as rules.
- A rule is the technical implementation of a policy for a specific security benchmark.
- Remediations, when applied, help you meet a specific policy.
It is important to note that the operator will help you evaluate and report on your compliance status. It will also generate remediations so you can get closer to your compliance target. However, it won’t actively enforce the policies. We explicitly stayed away from this responsibility as to let other projects do it and play well with the ecosystem.
OPA
OPA (Open Policy Agent) is a project that I’m very excited about! It’s a general-purpose engine that helps you enforce and verify policies in a centralized and dynamic manner. It introduces a language called rego which you must use to express your policies, and it brings up a whole set of tools and helpers to help you develop policies to your needs.
OPA is generic enough to be usable in many scenarios. For instance:
-
You could use it to enforce authorization policies on your microservices.
- Can Alice access the admin page?
- Can Bob read Kirsti’s user details?
-
You could use it to test your Kubernetes manifests or other configuration data
-
You could use it as an admission controller for Kubernetes
And there’s many other use-cases.
Gatekeeper
Gatekeeper helps you dynamically write and enforce policies for your Kubernetes deployment using CRDs. It’ll make sure that the policies you set are respected through an admission controller, which will intercept any requests you make to Kubernetes and authorize them if they conform to the rules you define. Ultimately, you’ll write general policies as templates, and ask the operator to enforce them using constraints.
The Red Hat Community of Practice group is in fact writing a set of best practices for your OpenShift deployments as rego policies. These rules are directly written in rego, and take a tool called konstraint into use in order to generate the appropriate Custom Resources that Gatekeeper expects. The advantage of using Konstraint is that they are also able to test the rules using conftest.
How do the Compliance Operator and OPA/Gatekeeper tie together?
Ultimately, the Compliance Operator will help you report and evaluate, and OPA will help you enforce. In the future, I’d like us to start introducing rules in the ComplianceAsCode/content repo that check for specific Gatekeeper templates and constraints being set, them remediations would create these objects. This way, Gatekeeper will enforce rules that the Compliance Operator expects, and thus help your deployment stay compliant.
The Gatekeeper templates and constraints would show up in the report that the Compliance Operator generates, along with the explanations on why these rules are needed to meet the specific compliance benchmark. This would be read by your auditor, and help them understand the security controls you’ve put together to protect your deployment.
Conclusion
The Compliance Operator and OPA/Gatekeeper are not competing projects, and can very nicely compliment each other. The Compliance Operator evaluates and reports on your compliance status for both the nodes themselves and your kubernetes installation. While OPA/Gatekeeper enforces rules that are required to meet your compliance target for Kubernetes. Having both projects in place will make your life easier for meeting your compliance targets.
tags: openshift