Zugänge einrichten mit Network-Policy

Somit wäre dann auch das Setup der Trireme-Umgebung abgeschlossen. Was nun natürlich noch fehlt, ist die eigentliche Anwendung und die dazugehörige Policy, die den Zugang zu den einzelnen Anwendungen regelt. Das Github-Repository bietet auch hierfür einige Beispieldateien. Die eigentliche Anwendung besteht aus drei Pods. Zwei dieser Pods stellen eine Redis-Anwendung zur Verfügung. Einer der beiden Pods verfügt über das Attribut "role=WebFrontend", der andere bekommt das Attribut "role=External". Der dritte Pod stellt einen Nginx-Server zur Verfügung. Das dazugehörige Attribut, mit dem dieser Pod identifiziert wird, lautet "role=BusinessBackend". Die Network-Policy erlaubt einen Zugang zu den Pods mit dem Attribut "role=BusinessBackend" nur von Pods mit der gleichen Rolle oder wenn diese über das Attribut "role=WebFrontend" verfügen. Ein Zugriff von dem Pod mit dem Attribut "role=External" ist nicht gestattet.

Die folgenden Beispiele zeigen nun, wie sich diese Umgebung aufbauen lässt. Zuerst ist ein neuer Namespace zu erzeugen, in dem die Pods mit den Anwendungen laufen sollen. Als Name wählen wir hier "DemoNamespace":

# cd trireme-kubernetes/ deployment/PolicyExample

# oc create -f DemoNamespace.yaml

namespace "demo" created

Danach ist die Network-Policy an Kubernetes zu übergeben:

# oc create -f Demo3TierPolicy.yaml

networkpolicy "frontend-policy" created

networkpolicy "backend-policy" created

networkpolicy "database-policy" created

# oc get networkpolicy –namespace=demo
NAME                   POD-SELECTOR                 AGE
backend-policy      role=BusinessBackend         2m
database-policy     role=Database                     2m
frontend-policy      role=WebFrontend              2m

Zur Sicherheit können Sie wieder überprüfen, ob dieser Schritt erfolgreich war und Kubernetes die neue Policy kennt (siehe Listing 3). Schließlich starten Sie die eigentlichen Pods mit der Nginx- und Redis-Anwendung:

# oc create -f Demo3TierPods.yaml

pod "external" created

pod "frontend" created

pod "backend" created

Wie ein Blick in die YAML-Datei bestätigt, werden die Attribute, mit denen die Identität der Pods festgelegt wird, in den Metadaten über die Kubernetes-Label-Anweisung gesetzt. Schließlich kann ein Test erfolgen, ob unerwünschte Zugriffe von dem Pod mit dem Attribut "role=External" tatsächlich nicht möglich sind. Hierfür sind zuerst einmal die IP-Adressen zu identifizieren, die den einzelnen Pods zugewiesen wurden. Am einfachsten gelingt dies wieder mit dem oc-Tool:

# oc describe pods --namespace=demo | grep '^Name:\|IP'

Name: backend

IP: 172.17.0.2

Name: external

IP: 172.17.0.5

Name: frontend

IP: 172.17.0.4

Ein Shell-Zugriff auf die Pods erfolgt wieder mittels oc. Zuerst ein Test von dem Front-end- auf das Backend-System:

# oc exec --namespace=demo -it frontend /bin/bash

# curl -dump http://172.17.0.2

Hello IT-Adminitrator...

Hier klappt der Zugriff. Nun folgt der Test von dem Pod mit dem Attribut "role=External". Von hier sollte der Zugriff auf den Pod im Backend nicht funktionieren:

# oc exec --namespace=demo -it external /bin/bash

# curl -dump http://172.17.0.2

^C

Von hier klappt der Zugriff in der Tat nicht und die Verbindung läuft ins Leere. Somit sorgt Trireme in Verbindung mit der Kubernetes-Network-Policy in der Tat dafür, den Zugriff zwischen den einzelnen Pods zu steuern. Wer mag, der kann an dieser Stelle einmal den Trireme Pod beenden und dann erneut den Zugriff von dem externen Pod aus probieren. Diesmal sollte der Zugriff funktionieren. Die Pods werden zwar immer noch mit den entsprechenden Attributen gestartet, allerdings gibt es keine Instanz mehr, die die zuvor definierte Network-Policy auch tatsächlich erzwingt.

Fazit

Mit Trireme lässt sich eine Segmentierung auf Anwendungsebene sehr leicht umsetzen. Das Schöne an dem Framework ist, dass es sich leicht in bestehende Umgebungen integrieren lässt und auch keinerlei Änderungen am Programmcode der eingesetzten Applikationen erfordert. Mit Hilfe von preshared Keys oder auch Zertifikaten lässt sich die Identität von Pods zweifelsfrei nachvollziehen. Das beugt auch Man-in-the-Middle-Angriffen in unbekannten und somit erst einmal unsicheren Netzwerken vor.

(dr)