© pryzmat / 123RF.com

Container vermitteln mit ihrer Dynamik und ihrer Flexibilität den Eindruck, sie seien von allen Regeln befreit. Compliance-Vorgaben gelten in Unternehmen aber auch für sie. In Form von Open Policy Agent und Gatekeeper gibt es zwei Lösungen, um Compliance in Kubernetes zu erzwingen.

Fragt man Entwickler und Admins, was ihnen an Containern besonders gut gefällt, hört man regelmäßig dieselben Antworten: Flexibel seien Container, dynamisch, leichter zu verwalten – zumindest behaupten das eingeschworene Container-Fans. Tatsächlich verkörpern Container besonders gut die Ideen agiler Entwicklung, wofür symbolisch die Cloud-ready-Architektur mit ihrem Prinzip der Mikrodienste steht.

Was Entwickler und Admins in Sachen Flexibilität und Dynamik begeistert, treibt Compliance-Verantwortliche und CISOs jedoch regelmäßig Sorgenfalten auf die Stirn: Allzu groß ist bei manchem Entwickler oder Administrator die Versuchung, ein fertiges Image für Container aus dem Internet zu verwenden, es auf der eigenen Infrastruktur auszurollen und “Works for me” zu postulieren, ohne die Sicherheits- und Compliance-Implikationen des Vorgangs in Betracht zu ziehen. Wir sind bereits in der Vergangenheit auf diese Problematik eingegangen, doch es schadet nicht, zumindest einen weiteren kurzen Blick auf das Thema Container-Compliance zu werfen.

Compliance

Die Relevanz von Sicherheit und Compliance im Container-Kontext ist kaum zu überschätzen. Zwar laufen Container heute regelmäßig nicht mehr mit den Rechten des Systemadministrators Root – obwohl sie könnten, wenn es der Admin so will; auch dies ist ein Compliance-Thema. Dennoch vermag ein Container-Abbild aus dubioser Quelle mit eingebautem Bitcoin-Miner bereits die Stabilität eines Setups im Hinblick auf Netzwerk und Storage zu gefährden.

Als mindestens ebenso groß erweisen sich die Gefahren, die von Bastel-Images eigener Produktion ausgehen. “Works on my Macbook Air in VMware” hat sich zum geflügelten Wort für Einfaltspinsel entwickelt, die ein Image lokal zusammenbasteln und es danach in der Welt verteilen, ohne die Quellen oder eine nachvollziehbare Liste der Arbeitsschritte mitzugeben. Dem Admin, der ein solches Abbild nutzt, fliegt es spätestens beim ersten Security-Check um die Ohren: Findet sich in einem der Dienste im Container eine aus der Ferne ausnutzbare Schwachstelle, ist guter Rat teuer, wenn man nicht weiß, wie sich das Image mit einer neuen Version des Diensts bauen lässt und wo der Admin sie gegebenenfalls herbekommt.

Für Compliance-Beauftragte und CISOs lautet die Devise deshalb ganz klar, dass Container-basierte Setups weder mehr noch weniger Compliance und Security brauchen als ihre konventionellen Verwandten: Sie benötigen eine andere, aber ebenso gut überwachte Compliance. Hier kommt einerseits der Open Policy Agent mit seinem Kubernetes-Sidecar ins Spiel und andererseits Gatekeeper, ein eigens für Kubernetes gebauter Policy-Enforcement-Dienst, der im Hintergrund allerdings auf den Open Policy Agent (OPA [1]) setzt.

Viel Verwirrung

Anwender und Admins, die sich mit den beiden Komponenten erstmals befassen, verwirren deren Namen regelmäßig: Gatekeeper firmiert im Netz regelmäßig auch als OPA 1.0, und die Begriffe Open Policy Agent mit Kubernetes-Sidecar sowie Gatekeeper als Kubernetes Policy-Engine scheinen irgendwie miteinander in Verbindung zu stehen. Wer sich mit beiden Komponenten befasst, tut deshalb im ersten Schritt gut daran zu klären und zu verstehen, worin sich Open Policy Agent und Gatekeeper unterscheiden.

Allerdings lässt sich die Frage gar nicht schlüssig beantworten, denn Open Policy Agent und Kubernetes-Sidecars sind zwei voneinander getrennte Komponenten. Der Open Policy Agent entstand zwar ursprünglich im Kontext vom Kubernetes, heute handelt es sich bei diesem Produkt aber um eine autarke Komponente. Sinn und Zweck des OPA bestehen darin, eine völlig generische Methode zu bieten, um Compliance-Regeln zu definieren und in Programmen jedweder Art das Einhalten dieser Regeln zu überprüfen. Ein ganz einfaches Beispiel wäre die Regel, dass ein Webserver nicht auf Port 80 lauschen darf, sondern Port 443 nutzen muss, also SSL-Verschlüsselung. Mittels des OPA und einer Integration des Webservers in OPA ließe sich im Anschluss prüfen, ob das tatsächlich der Fall ist.

Kubernetes kommt erst deutlich später ins Spiel – hier dient OPA als sogenannter Admission Controller (Abbildung 1). Aus Sicht des Admins ergeben sich zwei verschiedene Möglichkeiten. Einerseits lässt sich der OPA über ein Sidecar mit Kubernetes verbinden. Das Sidecar ruft dann die definierten Compliance-Regeln regelmäßig ab und prüft, ob die ausgerollte Anwendung sie einhält. Gatekeeper stellt eine Weiterentwicklung dieses Prinzips dar: Es gehört als Komponente zu den Deployments in Kubernetes und erzwingt die Umsetzung von Compliance-Regeln direkt auf der Container-Ebene.

Abbildung 1: Admission Controllers sind eine in Kubernetes ab Werk vorgesehene Methode, Compliance-Schutz zu gewährleisten. Quelle: Kubernetes

Dieser Artikel stellt einerseits OPA und seine möglichen Einsatzgebiete vor und zeigt andererseits, wie die Integration per Sidecar oder per Gatekeeper in Kubernetes funktioniert.

OPA im Fokus

Zugegeben, ganz neu ist die Idee hinter OPA nicht. Auf dem Markt gibt es schon diverse andere Implementierungen von Policy-Frameworks wie Chef InSpec [2], in dem man in einer eigenen Sprache Regeln für Compliance-Checks definiert und das die festgelegten Parameter danach erzwingt. Wozu braucht es OPA überhaupt? Selbstbewusst beantworten die Leute hinter der Lösung diese Frage auf ihrer Website: Anders als andere Lösungen eigne sich OPA für Cloud-Native-Umgebungen. Allein: Nach diesem Satz ist der geneigte Leser so klug wie zuvor. Wo die Stärken von OPA tatsächlich liegen, zeigt erst der genauere Blick etwa auf die Architektur der Lösung (Abbildung 2).

Abbildung 2: Die Architektur des Open Policy Agents zeigt: Bei OPA handelt es sich um ein generisches Werkzeug für Policy-Erzwingung. Quelle: OPA

Aufgabenteilung

Eine Kerneigenschaft fällt bei OPA sofort auf: Das Werkzeug unterscheidet in seinen eigenen Prozessen zwischen dem Festlegen und Erzwingen von Policy-Entscheidungen. Andere Compliance-Werkzeuge folgen hier dem klassischen Automatismus, dass eine Entscheidung im Hinblick auf eine Policy automatisch zu deren Erzwingen führt. Stellt InSpec etwa fest, dass ein Dienst auf einem verbotenen Port lauscht, gibt es sofort eine Fehlermeldung aus und bricht seine Arbeit ab.

In heutigen verteilten Applikationen ist dieser Automatismus so aber möglicherweise gar nicht gewünscht. Entzerren lässt sich das nur, wenn die Policy-Entscheidung und die daraus zu ziehenden Konsequenzen von unterschiedlichen Instanzen kommen. Genau darin sieht OPA seinen Use Case: Er ermöglicht externen Programmen, anhand festgelegter Regeln Compliance-Tests vorzunehmen, überlässt die Entscheidung über Konsequenzen dann aber den jeweiligen Applikationen.

Wie funktioniert das im Detail? Unter der Haube unterscheidet OPA zwischen der eigenen Policy Engine und dem Teil der Anwendung, der Daten verarbeitet. Externe Applikationen wenden sich mit Anfragen an OPA, die lediglich Daten in strukturierter Form nach JSON-Standard enthalten. So könnte etwa ein auf einem Zielsystem laufender Dienst eine Liste aller Netzwerkschnittstellen des Hosts kompilieren und diese hinterher an OPA senden. Im nächsten Schritt des Vorgangs kommt dann die Policy-Engine von OPA zum Einsatz.

Deklarativ auf Datadog-Basis

Die OPA-Entwickler haben dafür eine eigene deklarative Sprache namens Rego gebaut. Dabei handelt es sich allerdings nicht um eine komplette Neuentwicklung: Sie erinnert stark an das etablierte Datadog, das allerdings schlicht zu alt ist, um JSON als Format zu unterstützen. Rego besteht im Wesentlichen aus Datadog mit minimalen Änderungen und einer JSON-Erweiterung.

Auf Basis von Rego definiert der Administrator das Regelwerk, das OPA beim Bewerten von eingehenden Compliance-Anfragen nutzt. Die Entwickler stellen in ihrer Dokumentation eine komplette Anleitung für Rego [3] zur Verfügung und gehen auch auf Besonderheiten ein wie die Möglichkeit, Rego mit Modulen zu versehen. Zweifelsohne der wichtigste Faktor bei Rego ist allerdings, dass es für Antworten an anfragende Dienste zwar eine festgelegte Form, aber keine festen Inhalte gibt. So wie der ursprüngliche Request im JSON-Format daherkommen muss, muss auch die Antwort auf eine Compliance-Anfrage das Gegenüber im JSON-Format erreichen. Was inhaltlich in der Antwort steht, definiert allerdings der Admin, der die Compliance-Regel schreibt, und nicht OPA auf Basis etwaiger Standardannahmen.

Im letzten Schritt schickt OPA der anfragenden Stelle die Antwort auf die Compliance-Anfrage – und überlässt dieser vollständig die Entscheidung, wie diese mit einem eventuell negativen Resultat umgeht.

Komplex und vielseitig

Der beschriebene Prozess des Policy Checkings in OPA ist freilich deutlich komplexer, als das einfache Beispiel es darzustellen vermag. Das liegt in erster Linie an der Vielzahl der Features in OPA. Rego als deklarative Sprache für das Festlegen von Policy-Regeln bietet mittlerweile Unterstützung für über 150 Funktionen, die JSON interpretieren, darüber iterieren und es bei Bedarf auch verändern.

Wer sich bei OPA allerdings nur auf die Policy Engine konzentriert, tut dem Datenteil der Lösung unrecht. Denn auch der ist ausgesprochen leistungsfähig, und – fast noch wichtiger – kann Daten in einen Kontext stellen. Konkret bedeutet das, dass die Policy Engine von OPA Entscheidungen nicht nur auf Basis der Informationen eines einzelnen Programms treffen kann, sondern in seine Berechnungen auch Daten von anderen Diensten oder Servern einzubeziehen vermag. Der Admin kann seine Systeme etwa so konfigurieren, dass sie eine Vielzahl unterschiedlicher Daten regelmäßig bei OPA abladen. Im nächsten Schritt greifen Checks auf die gesamten verfügbaren Daten zurück.

Dadurch unterscheidet OPA sich erheblich von anderen Compliance-Werkzeugen. Deren Arbeitsablauf sieht meist vor, unterschiedliche Daten unmittelbar in Relation zueinander zu setzen, etwa durch das Definieren von statischen Profilen. Was für konventionelle Lösungen sinnvoll gewesen sein mag, verursacht in dynamischen Umgebungen wie Clouds möglicherweise ein Problem, denn es besteht die Gefahr, dass spätere Admins vor Urzeiten eingerichtete Checks kaum noch nachvollziehen können. Die in Clouds impliziten Veränderungen der Umgebung würden obendrein dazu führen, dass man Profile und die Verbindungen zwischen ihnen regelmäßig warten und aktuell halten müsste, was in hochdynamischen Umgebungen zu einer Sisyphosarbeit wird.

Clients einbinden

Bleibt letztlich die Frage, wie Entwickler OPA in ihre Lösungen integrieren. Hier ergeben sich mehrere Möglichkeiten. Die gängigste Variante besteht darin, OPA als typischen Linux-Daemon zu betreiben und Anfragen an ihn im ReST-Format zu verfassen. Dieser Ansatz zielt offensichtlich voll und ganz auf Cloud-Umgebungen ab, deren einzelne Komponenten ohnehin regelmäßig per HTTPS miteinander sprechen. Die API von OPA ist freilich quelloffen und gut dokumentiert, sodass Entwicklern die Integration leicht von der Hand geht.

Die zweite Option für die OPA-Integration besteht darin, den Dienst mittels einer Go-Bibliothek gleich auf der Progammierebene zu implementieren. Weil die Bibliothek nur für Go zur Verfügung steht, kommt dieser Ansatz freilich vorrangig für Go-Werkzeuge zur Geltung. Die Programmiersprache Go erfreut sich gerade im Cloud-ready-Umfeld allerdings extrem hoher Beliebtheit, sodass das für die meisten aktuellen Entwickler in Ordnung gehen sollte.

Nicht nur Kubernetes

Spätestens an dieser Stelle wird auch klar, dass OPA längst nicht mehr nur ein Anhängsel für Kubernetes ist und das eigentlich auch nie war. Die Möglichkeiten, OPA für Compliance-Entscheidungen zu nutzen, gehen weit über Kubernetes hinaus, wie einige Beispiele eindrücklich zeigen. Das PAM-System (Pluggable Authentication Module) für Linux etwa bietet die Möglichkeit, das Authentifizieren von Benutzernamen in separate, in Reihe schaltbare Module auszulagern. Als eine Art Beweis, dass OPA hier sinnvoll mitspielen kann, haben seine Entwickler ein PAM-Modul geschrieben, das im Hintergrund mit OPA kommuniziert (Abbildung 3). Hat ein Nutzer in den Daten von OPA die Rolle eines Admins, erlaubt das OPA-Modul ihm die Anmeldung. Auch Sudo lässt sich auf diese Weise mit OPA koppeln.

Abbildung 3: Mittels PAM lässt sich für OPA auch ein anderer Use Case als Kubernetes finden. Am häufigsten kommt das Werkzeug aber wohl noch immer per Kubernetes zum Einsatz.

Sonderlich originell ist das Beispiel freilich nicht, denn ähnliche Effekte lassen sich mit Bordmitteln und LDAP auch erreichen. Spinnt man das Beispiel aber eine Stufe weiter, wird ein Schuh daraus: Ein eigener Daemon etwa könnte die gerade auf dem System eingeloggten Benutzer mit einer Whitelist erlaubter Logins abgleichen. Ist jemand eingeloggt, der nicht auf der Gästeliste steht, schlägt das Tool Alarm, und ein Admin sieht sich die Sache an. Auch in weiteren Kontexten lässt OPA sich gut und sinnvoll nutzen, etwa im Orchestrierer Terraform oder in Envoy, das im Linux-Magazin als Mesh für Kubernetes bereits ausführlich Thema war [4].

In diesem Artikel geht es letztlich um die Frage, wie sich bestimmte Compliance-Themen in Kubernetes erzwingen lassen. Nun, da klar ist, dass OPA das passende Fundament dafür bietet, stellt sich eine konkrete Frage: Wie implementiert der Admin einen Kubernetes-Wachhund, der sich mit OPA im Rücken um das Umsetzen der vom Administrator definierten Regeln kümmert? Hier kommen wieder die beiden Möglichkeiten ins Spiel, die bereits ganz am Anfang dieses Artikels Thema waren: Das Kube-mgmt-Sidecar für OPA sowie der eigentliche Gatekeeper. Grundsätzlich gilt: Beide Werkzeuge zielen darauf ab, mittels OPA Compliance-Entscheidungen in einem Kubernetes-Cluster zu ermöglichen. Sie tun das allerdings höchst unterschiedlich.

Das Sidecar

Wie bereits beschrieben initiiert OPA selbst keine Maßnahmen, falls ein Policy-Check ein negatives Ergebnis bringt. Es stößt auch selbst nicht die entsprechenden Checks an, sondern stellt lediglich die Engine zur Verfügung, die externe Komponenten nutzen können. Das bedeutet freilich einerseits auch, dass der Admin passende Compliance-Regeln für Kubernetes in OPA hinterlegen muss – das ist relativ einfach. Andererseits muss er Kubernetes eine Komponente zur Seite stellen, die die dortigen Workloads ausliest, die Compliance-Prüfung durch OPA initiiert und gegebenenfalls Maßnahmen ergreift, falls diese fehlschlägt.

Das Kube-mgmt-Sidecar ist die ältere der existierenden Lösungen für diesen Zweck. Es erledigt mehrere Arbeitsschritte parallel: Zunächst rollt es OPA automatisiert in einen bestehenden OPA-Cluster aus. Der Admin braucht sich hier also nicht mehr damit zu beschäftigen, wie er OPA zum Laufen bekommt, denn das erledigt Kube-mgmt inklusive der Redundanz. Lediglich um ein passendes SSL-Zertifikat muss er sich kümmern, denn damit Kubernetes anschließend mit OPA kommunizieren kann, besteht es zwingend auf einer verschlüsselten Verbindung. Ist diese hergestellt, lässt OPA sich aus Kubernetes heraus nutzen – etwa um das Anlegen von Ressourcen zu vermeiden, die bestimmten Vorgaben nicht entsprechen.

Betrachten wir das Beispiel einer Unternehmensrichtlinie, die vorgibt, dass sämtliche ins Internet geöffneten Dienste unter der Domäne http://example.net auf Port 443 erreichbar sein müssen. Dazu hinterlegt der Administrator in OPA entsprechende Policies für Kubernetes. Er erzeugt zu diesem Zweck per Kubectl einen Eintrag des Typs »ConfigMap«, wobei die Datei die reine Anweisung für OPA in Rego enthält. Dabei unterstützen den Admin Rego-Funktionen wie »fqdn_matches_any« oder »fqdn_matches«, mit denen sich Host-Namen automatisiert prüfen lassen.

Das »ConfigMap«-Objekt enthält lediglich die Logik, die anhand der Parameter festgelegter Hosts die Policy-Entscheidung trifft. Die Domains selbst hinterlegt der Admin also nicht dort, sondern mittels Annotation-Direktive in der Pod-Definition des Namespaces, in dem die Zieldienste laufen sollten. Regelmäßig möchten Admins in ihren Clustern eigene Namespaces für verschiedene Compliance-Anweisungen anlegen, um die Übersicht zu verbessern. Schließlich legt der Admin fest, dass die vorhandene OPA-Instanz als Admission Controller für Kubernetes fungiert, dass also Kubernetes Compliance-Entscheidungen an OPA auslagert.

Der Rest ist dann Schema F: Startet der Admin in seinen Namespaces Instanzen wie Ingress-Controller, legt er wie üblich per »serviceName« und »servicePort« deren Basisparameter fest. Widersprechen diese den Vorgaben, die der Admin vorher durch OPA gemacht hat, verweigert K8s das Anlegen der entsprechenden Ressource mit passender Begründung. Salopp formuliert ist die Compliance-Kontrolle per Kube-mgmt also die kleine und etwas einfachere Lösung.

Komplettlösung

Einen etwas anderen Ansatz verfolgt Gatekeeper. Die Unterschiede liegen hier tatsächlich in den Details, und das auch erst in den späteren Teilen des Setups. Zunächst braucht der Admin auch in einem Setup mit Gatekeeper eine laufende OPA-Instanz. Ist Gatekeeper in Kubernetes aber erst einmal aktiv, erweitert es diese um Custom Resource Definitions (CRDs), die das automatisierte Starten von OPA ermöglichen (Abbildung 4). Es existiert dann auch nicht nur eine OPA-Instanz, sondern so viele Instanzen, wie der Admin und die Nutzer initiieren.

Abbildung 4: Gatekeeper schaltet sich über CRDs und eigene Policy Templates in Kubernetes als Admission Controller ein und bestimmt so über Wohl und Wehe von Ressourcen. Quelle: Gatekeeper

Und noch ein Detail ist fundamental anders: Beim Einsatz von Gatekeeper legt der Admin die Compliance-Regeln nicht selbst in OPA fest. Dafür bringt Gatekeeper stattdessen einen Wrapper mit, über den der Admin über die Policy-Regeln als Constraint-Templates einspielt, aus denen der Nutzer selbst Constraints macht. Das erweist sich im Alltag als ausgesprochen praktisch, weil so nicht nur Admins mit Zugriff auf OPA Compliance-Regeln festlegen können, sondern auch normale Benutzer mit Zugriff auf Kubernetes. Praktisch dürfen Anwender so viele Templates mit Constraints für OPA anlegen wie sie wollen und können diese auf verschiedene Ressourcen dynamisch anwenden. Das ist viel flexibler als die Lösung des Vorgängers.

Besser auf Compliance ausgerichtet

Auch darüber hinaus haben es zwischen Kube-mgmt und Gatekeeper viele Gemeinsamkeiten und wenige – dafür aber handfeste – Unterschiede. Beide Ansätze produzieren etwa Logfiles, die sich mit zentralisierten Logging-Werkzeugen wie ELK oder Loki problemlos einsammeln lassen. Weil im Zentrum beider Ansätze OPA selbst steht, lässt es sich obendrein in beiden Fällen so konfigurieren, dass es Logs über seine Entscheidungen in Sachen Compliance direkt per HTTP an einen externen Server versendet. Dort könnte der Admin sie beispielsweise abgreifen und zum Teil eines Audit-Logs machen, das etwaige Zertifizierungsstellen mit einiger Wahrscheinlichkeit sehen wollen (Abbildung 5).

Abbildung 5: Gatekeeper ist ab Werk etwas besser darauf vorbereitet, selbst auditiert zu werden, als es bei Kube-mgmt der Fall ist.

Alternativ kann der Admin in Gatekeeper aber auch dessen Feature für einen Audit-sicheren Trail nutzen. Es loggt ebenfalls Entscheidungen im Hinblick auf Compliance und macht sie in den Constraint-Einträgen in K8s unmittelbar sichtbar.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-gk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["gatekeeper"]

Kube-mgmt oder Gatekeeper?

Wie man es auch dreht und wendet: Die Details, die OPA mit Kube-mgmt auf der einen und Gatekeeper auf der anderen Seite voneinander unterscheiden, fallen nicht weltbewegend aus. In beiden Fällen kommen dieselben aktuellen OPA-Versionen zum Einsatz; in beiden Fällen muss der Administrator die Konfiguration eines Kubernetes-Clusters ändern, um OPA als Admission-Controller zu verwenden.

Gatekeeper hat hier womöglich eine Nasenlänge Vorsprung, weil es die Policy-Konfiguration aus K8s heraus ermöglicht, während bei der Kube-mgmt-Variante der Admin der OPA-Instanz selbst zu Leibe rückt. Das macht aber nur dort einen relevanten Unterschied, wo der Admin des Workloads in K8s nicht der Admin ist, der das Kubernetes selbst betreibt.

Wer sich zum ersten Mal mit dem Thema Zulassungskontrolle und den verschiedenen Faktoren beschäftigt, anhand derer sich in Kubernetes über Erlaubnis oder Verbot für das Erstellen von Ressourcen entscheiden lässt, kommt mit Kube-mgmt vermutlich etwas besser zurecht als mit dem größeren Gatekeeper.