Watchdog

Focus on OPA

Admittedly, the idea behind OPA is not entirely new. Various other implementations of policy frameworks are already on the market, such as Chef InSpec [2], for which you define rules for compliance checks in a separate language and which then enforces the defined parameters. Why is OPA needed at all? The people behind the solution confidently answer this question on their website: Unlike other solutions, OPA is suitable for cloud-native environments. After this statement, however, you are not more informed. Where the strengths of OPA actually lie can only be seen by taking a closer look at the architecture of the solution (Figure 2).

Figure 2: As the architecture of the Open Policy Agent shows, OPA is a generic tool for policy enforcement. © OPA

Task Sharing

One core feature immediately stands out in OPA: The tool distinguishes between setting and enforcing its own processes in policy decisions. Other compliance tools follow classic automation, wherein a decision relating to a policy automatically leads to its enforcement. For example, if InSpec detects that a service is listening on a prohibited port, it immediately outputs an error message and stops it.

In today's distributed applications, however, this level of automatism might not be desired. This conflict can only be rectified if the policy decision and the consequences to be taken from it come from different instances, which is exactly where OPA sees its use case: It enables external programs to perform compliance tests according to defined rules but then leaves the decision about consequences to the respective applications.

How does this work in practice? Under the hood, OPA distinguishes between its own policy engine and the part of the application that processes data. External applications turn to OPA with requests that contain data in the structured JSON format. For example, a service running on a target system could compile a list of all the host's network interfaces and send it to OPA afterwards. The next step in the process is to use OPA's policy engine.

Rego Declarative Language

The OPA developers have built their own declarative language named Rego for this purpose. However, this development is not completely new: It is strongly reminiscent of the established Datadog, which, however, is simply too old to support the JSON format. Rego essentially consists of Datadog with minimal changes and a JSON extension.

With Rego, you define the set of rules that OPA uses when evaluating incoming compliance requests. The developers provide a complete guide to Rego [3] in their documentation and also address special features, such as the ability to add modules. Undoubtedly, however, the most important factor in Rego is a fixed form for responses to requesting services but no fixed content. Just as the original request must come in JSON format, the response to a compliance request must also reach the counterpart in JSON format. However, you define the content of the response and write the compliance rule, rather than OPA doing so on the basis of any standard assumptions.

In the final step, OPA sends the response to the compliance request to the requesting agency – leaving it entirely up to the agency to decide how to handle any negative outcome.