My name is Anatolii Kaliuzhnyi, and I’m a DevOps Engineer at SoftServe Kharkiv and a local DevOps Community Lead. Now, I’m leading 2 projects where we use Open Policy Agent (OPA). Even though it’s a cool tool for better protection and control of created resources, quite a small number of specialists know what OPA is and how to use it. That’s why, in this article, I’d like to share the theoretical part and explain how to configure Open Policy Agent.

This topic will benefit specialists working on projects with a shared Kubernetes cluster, any engineer interested in security, and those with a client that longs for more control over clusters.

What is Open Policy Agent

I’d like to start with explaining what this Open Policy Agent (OPA) beast is. Its task is quite utilitarian and simple—to make a user execute policies set by an administrator. The policies can be different – business, technical, administrative, or any other you come up with. The tool itself doesn’t have any restrictions to its usage.

Here is OPA example used by developers: a bank worker has access to the database of all bank accounts, and we want to restrict their access to accounts’ details. We want a worker to have access only if this worker is processing an open request from this customer. This won’t allow uncontrolled opening of customer data even though the employee has access to all accounts. Therefore, it improves security and reduces risks.

Namely, OPA regulates how and when a resource can be requested. But how does it relate to Kubernetes and DevOps in general? It appears that it’s possible to regulate the deployment in the same way. For example, not allowing to create Deployments where the image field in Pod contains the repository from the not allowed list. The workflow of the service is quite simple: a request comes via a webhook, the request is intercepted by OPA (must be is JSON), processed following the policy, and a decision on whether to allow the request or deny it is made. To give more information, it’s also possible to provide the reason for the denial.

/uploads/stories/principles-of-open-policy-agent-dot-practical-use-in-kubernetes/opa.jpg?1655231526219

There are three versions of OPA, however, two of them are outdated and one is current. In old versions, ConfigMap was used as the main depository for policies, where policies themselves and data to form responses were set. It was convenient to use, however, the progress continues. Thus, in a new third version, it was decided to change the approach in the favor of a new progressive model—Customer Resource Definition. Here, a policy template is a resource type, and specific data related to the policy (forming the policy) is a resource itself.

Real usage OPA examples

In practice, I’ve used OPA for a blockchain NFT startup. The task was to introduce standards of joint resources usage, Kubernetes cluster in particular. So, with OPA, we got more control over them.

All in all, such innovation was easily accepted by other teams on the project. However, just during the introduction of OPA some issues that we didn’t have time to resolve before appeared. And at that time, we had no other choice but to fix them because OPA couldn’t be introduced otherwise.

How to install and configure OPA

It’s possible to install OPA with the help of a helm chart as well as via manifests. I recommend using helm. The official chart is available via the link.

Install as a usual chart not giving off a separate namespace for the manager:

Kubectl create namespace gatekeeper-system

Then install the chart:

helm repo add opa https://open-policy-agent.github.io/gatekeeper/charts

helm install gatekeeper opa/gatekeeper -n gatekeeper-system

The most important thing in working with OPA is accurate configuration of the policies. They are written using a special open policy agent language—rego. The language itself is a set of rules and functions (for simplicity and reuse) for setting restrictions and permissions. You can create both allowing rules and restricting ones. The simplest way is to use one type of rule by default (if not restricted—allowed, and vice versa). Luckily, there already is quite big library of rules written by OPA developers. It has a comprehensive list of policies that can be used in different cases. If you need to create a policy from scratch and there is no such policy in the library, you’ll get to learn all the advantages of rego. And I recommend you create a bookmark playground for rego right away.

Without this tool, it will be quite difficult to understand why a policy doesn’t work. It also allows to highlight executed instructions and see the execution result of your policy in real time.

Let’s have a look at the principle of policy setting. Any policy will consist of a template—a set of rules (rego) and a resource of the policy itself with variables, based on which it will be determined how the policy will react specifically to your cluster and your requests to us. That is, when you write the policy, you start from the variables that you can set later based on the project requirements for a particular cluster.

Understand policies

When using a tool that literally forces engineers to use the best practices in the world, there is no chance not to use them. It’s as if a policy says to do everything right at the first time. What is more, with different policies, it’s possible to control the security of the cluster from one place. It is convenient when the cluster is used by more than one team, and one can’t control what each team does.

These are the policies we used on the project:

gatekeeper-library. Requires CPU and memory limits, and you can set your maximum limit for this.
allowedrepos. Indicates repositories from which you can take the docker image for the cluster (ideally, leave only your internal repository and take all images from it).
requiredannotations. Requires resource-specific annotations.
requiredlabels. The same, only for labels.
privileged-containers. Prevents containers from running in privileged mode (exceptions can be specified).

By specifying only these policies, you can considerably improve the security of your cluster.

Conclusions

In general, the tool, with the right skills and settings, is totally suitable for use as one of the security components of your infrastructure in cooperation with other tools. OPA allows you to force engineers to use the best practices in the management and use of Kubernetes without them being able to avoid these limitations. It also allows to protect the cluster from improper and careless interactions.