Seite 2: Security und Compliance

Inhaltsverzeichnis

Ohne ein ausreichendes Security- und Compliance-Niveau geht bei größeren Unternehmen gar nichts. Darum wundert es nicht, dass bei der diesjährigen CloudNativeCon in San Diego der Open Policy Agent (OPA) einen ähnlichen Hype ausgelöst hat wie im Jahr davor Istio.

OPA ist ein CNCF-Projekt, mit dem sich Policys programmieren, provisionieren sowie durchsetzen und dabei überwachen lassen. Als Grundlage für die Vorgaben dient die proprietäre Sprache Rego, und die OPA-Agenten prüfen sie. Letztere sitzen als dedizierter Service oder eingebettet per Go-Bibliothek nahe an dem mit Policys gesteuerten Workload. Der Anwendungsbereich ist vielfältig und beliebig erweiterbar: Steuerung von Authentifizierung und Autorisierung, Compliance-Checks in der CI/CD Pipeline, Kontrolle des Service-Mesh und der Kubernetes-Konfiguration. OPA ist unabhängig von Kubernetes – die Agenten laufen auch außerhalb eines Clusters. Mit OPA lassen sich somit vielfältige Compliance- und Security-Policys per Code definieren und umsetzen und somit ein umfassender Security-Stack aufbauen.

Gemäß dem Prinzip "Shift Left" können Security-Checks Bestandteil des CI/CD-Prozesses werden. Dafür steht unter anderem das Werkzeug Conftest zur Verfügung, mit dem sich über in Rego formulierte Policy-Checks zahlreiche Konfigurationsdateien wie YAMLs, JSONs, TOMLs und Dockerfiles definieren und prüfen lassen. Kubernetes Admission Controller oder die darauf aufbauende OPA-Integration Gatekeeper sind im Anschluss der Türsteher ins Kubernetes-Cluster und lassen nur Veränderungen zu, die allen definierten Policys genügen.

"Shift Left" benötigt ebenfalls Security-Maßnahmen, die zur Laufzeit wirken. Kubernetes bietet mit den PodSecurityPolicies und NetworkPolicies wirksame Sicherheitsvorkehrungen – idealerweise begleitet von einer Policy-fähigen und eBPF-basierten (Extended Berkeley Packet Filter) Netzwerkvirtualisierung wie Calico oder Cilium. Das reduziert die Angriffsfläche im Netzwerk deutlich. Mit dem CNCF-Projekt Falco steht ein Werkzeug zur Verfügung, das die Angriffsfläche auf die Workloads deutlich reduzieren kann. Falco überwacht das Laufzeitverhalten von Containern und schreitet ein, wenn es eine Anomalie oder gar ein Eindringen erkennt.

Ein weiteres Tool zum Umsetzen von Sicherheitsmaßnahmen zur Laufzeit sind Service-Meshes. In dem Bereich hat es Linkerd geschafft, den Hype rund um Istio zu brechen. Obwohl Letzteres weiter der "Feature-König" ist, schätzen viele Linkerd wegen der deutlich geringeren Komplexität und der besseren Betreibbarkeit – auch wenn Istio mit Version 1.4 in den Bereichen deutliche Verbesserungen mitbringt. Das Service-Mesh steht zusätzlich in der Kritik, weil es kein neutrales CNCF-Projekt ist und den auf der CloudNativeCon EU im Mai angekündigten Service-Mesh-Standard SMI nur widerwillig adaptiert. Ein Service-Mesh arbeitet oft Hand in Hand mit einem API-Gateway als Eingangstor. In dem Bereich gewinnt insbesondere Gloo an Sichtbarkeit. Vergleichbar zur Service-Mesh- Prominenz basiert Gloo auf Envoy als Proxy-Technik und integriert sich als Ingress in die Kubernetes-Welt.