Watchdog

Complex and Versatile

The described process of policy checking in OPA is admittedly far more complex than this simple example is able to depict, primarily because of the large number of features in OPA. Rego, as a declarative language for setting policy rules, now provides support for more than 150 functions that interpret JSON, iterate over it, and modify it as needed.

Anyone who focuses only on the policy engine in OPA, however, is doing an injustice to the data part of the solution because it is also extremely powerful and, almost more importantly, can put data into context. In concrete terms, this means that OPA's policy engine can not only make decisions on the basis of information from a single program, it can also include data from other services or servers in its calculations. For example, you can configure your systems to offload a variety of different data to OPA on a regular basis. In the next step, checks draw on all the available data.

This versatility makes OPA very different from other compliance tools. Their workflow usually involves relating different data to each other directly (e.g., by defining static profiles). What may have made sense for conventional solutions can cause a problem in dynamic environments such as clouds because the risk is that later admins will find it very difficult to reconstruct checks that were set up ages ago. The implicit changes in the environment in clouds would also mean that profiles and the connections between them would have to be maintained and kept up to date regularly, which becomes a Sisyphean task in highly dynamic environments.

Including Clients

Ultimately, the question remains of how developers integrate OPA into their solutions; you have several possibilities here. The most common variant is to run OPA as a typical Linux daemon and to write requests to it in REST format. This approach is obviously aimed squarely at cloud environments, in which individual components regularly talk to each other over HTTPS anyway. OPA's API is open source and well documented, so developers can integrate it easily.

The second option for OPA integration is to implement the service right at the programming level with a Go library. Because the library is only available for Go, this approach admittedly comes into its own primarily for Go tools. However, the Go programming language is extremely popular, especially in the cloud-ready environment, so this limitation should be fine for most current developers.

Not Only Kubernetes

At this point, at the latest, it also becomes clear that OPA is no longer just an appendage of K8s and never really was. The possibilities of using OPA for compliance decisions go far beyond K8s, as some impressive examples show. The pluggable authentication module (PAM) system in Linux, for example, lets you offload username authentication into separate modules that can be wired up in series. As a kind of proof that OPA can play along here in a meaningful way, its developers have written a PAM module that communicates with OPA in the background (Figure 3). If a user has the admin role in OPA's data, the OPA module allows them to log in – and couple sudo with OPA in this way.

Figure 3: With PAM, a use case other than Kubernetes can be found for OPA. However, the tool is probably still most commonly used with Kubernetes.

The example is not very original because similar effects can be achieved with on-board tools and LDAP. If you take the example a step further, however, things become more coherent: A separate daemon, for example, could compare the users currently logged in on the system with a whitelist of permitted logins. If someone is logged in who is not on the guest list, the tool raises an alarm and an admin takes a look. OPA can also be used well and sensibly in other contexts (e.g., in the Terraform orchestrator or in Envoy, which has already been discussed in detail in ADMIN as a mesh for Kubernetes [4]).

This article is ultimately about how to enforce certain compliance issues in K8s. Now that it is clear that OPA provides the appropriate foundations, a concrete question arises: How do you implement a K8s watchdog that, with OPA behind it, takes care of enforcing your defined rules? This is where the two options mentioned at the very beginning of this article come into play again: the kube-mgmt sidecar for OPA and Gatekeeper. Basically, both tools aim to enable compliance decisions in a K8s cluster with OPA. However, they do so in very different ways.