For compliance officers and chief information security officers (CISOs), the motto of the day is clear: Container-based setups need no more and no less compliance and security than their conventional relatives; they need different but equally well-monitored compliance. A container environment is where the Open Policy Agent (OPA) [1] with its Kubernetes sidecar on the one hand and the Gatekeeper policy enforcement service built specifically for Kubernetes (K8s) on the other hand enter the play. Of course, Gatekeeper relies on OPA in the background, as well.

In this article, I introduce OPA and its possible spheres of application and show how integration works with a sidecar or Gatekeeper in K8s.

Flexibility

If you ask developers and admins what they particularly like about containers, you regularly hear the same answers: Containers are flexible, dynamic, easy to manage – at least that's what sworn container fans claim. In fact, containers embody the ideas of agile development particularly well, symbolized by the cloud-ready architecture with its principle of microservices.

What excites developers and admins in terms of flexibility and dynamics, however, regularly puts worry lines on the foreheads of compliance officers and CISOs. All too great is the temptation for many a developer or administrator to use a ready-made image for containers from the Internet, roll it out on their own infrastructure, and just say, "well, it works for me," without considering the security and compliance implications of the operation. This issue has already been addressed in the past, but it doesn't hurt to take at least another quick look at the topic of container compliance.

Compliance

The relevance of security and compliance in the container context can hardly be overestimated. True, containers today no longer regularly run with the rights of the system administrator – although they could if the admin wanted them to, which is also a compliance issue. Nevertheless, a container image from a dubious source with a built-in Bitcoin miner can already endanger the stability of a setup in terms of network and storage.

The dangers of DIY images prove to be at least as great. "Works on my Macbook Air in VMware" has become a catchphrase for naive people who assemble an image locally and then distribute it around the world without providing the sources or a comprehensible list of the steps involved. Any admin who uses such an image will be blown away (at the latest) by the first security audit. If a remotely exploitable vulnerability is found in one of the services in the container, finding a way out can be expensive if you don't know how to build the image with a new version of the service or where you can find a legitimate version.

Much Confusion

Users and admins dealing with OPA and Gatekeeper for the first time are regularly confused by their names: Gatekeeper also regularly goes by the name OPA 1.0 on the web, and the terms "Open Policy Agent with Kubernetes sidecar" and "Gatekeeper as Kubernetes policy engine" somehow seem to be related. Anyone dealing with both components would therefore do well in the first step to clarify and understand how OPA and Gatekeeper differ.

However, the question cannot be answered conclusively because OPA and Kubernetes sidecars are two separate components. OPA was originally developed in the context of K8s, but today the product is a standalone component. The purpose of OPA is to provide a completely generic way to define compliance rules and to check for compliance in programs of any kind. A very simple example would be the rule that a web server must not listen on port 80 but use port 443 (i.e., SSL encryption). By means of OPA and an integration of the web server in OPA, you could then check afterwards whether this is actually the case.

Kubernetes comes into play much later. Here, OPA acts as an admission controller (Figure 1). From an admin's point of view, you have two different options. OPA can be connected to K8s by a sidecar. The sidecar then regularly retrieves the defined compliance rules and checks whether the rolled-out application adheres to them. Gatekeeper extends this principle: It belongs as a component to the deployments in K8s and enforces the implementation of compliance rules directly at the container level.

Figure 1: Admission controllers are a built-in method for providing compliance protection in Kubernetes. © Kubernetes