Attribute zur Trennung

Mit dem Trireme Framework [4] lässt sich nun sehr leicht solch ein neuer Lösungsweg beschreiten. Das Tool wurde von Aporeto entwickelt und führt eine Segmentierung auf Anwendungsebene durch. Hierfür setzt es auf die Identifizierung (Identity) und die Autorisierung (Autorization) einer Anwendung, bevor ein Kommunikationskanal zu eben dieser Anwendung aufgebaut werden kann. Das Prinzip ist dabei sehr einfach: Die Identität einer Anwendung wird bei Trireme mit Hilfe von Attributen (oder Labeln) definiert.

Ein Beispiel für solche Attribute könnte beispielsweise das folgende Set sein: "env=devel", "app=backend". Dieses einfache Set an Attributen könnte eine beliebige Backend-Anwendung innerhalb der Entwicklungsumgebung identifizieren. Eine einfache Autorisierungsregel könnte dann wie folgt lauten: "Akzeptiere Datenverkehr von jeder anderen Anwendung mit dem Attribut "env=devel"". Würde nun also beispielsweise eine Anwendung mit dem Attribut "env=prod" versuchen auf diese Anwendung zurückzugreifen, so würde Trireme diesen Zugang unterbinden.

Auch wenn das Framework nicht zwingend eine Container-basierte Landschaft voraussetzt, basieren alle Beispiele in diesem Artikel auf einer Umgebung, in der Kubernetes sich um den Lifecycle von anwendungsbasierten Containern kümmert. Wenn also von Attributen die Rede ist, mit deren Hilfe eine Anwendung identifiziert wird, dann gehen wir davon aus, dass diese Attribute für den Container gesetzt sind. Trireme greift hier auf die Labeling- und die Network-Policy-Funktion von Kubernetes zurück. Das Orchestrierungstool kümmert sich dabei um das Setzen der Attribute und Trireme sorgt für die Umsetzung der Policy, die auf diesen Attributen basiert.

Identitäten vergeben

Der aufmerksame Leser wird sich zu diesem Zeitpunkt aber sicherlich fragen, wie denn die Identität von Anwendungen überhaupt sichergestellt werden kann, wenn diese beispielsweise innerhalb einer Umgebung ablaufen, über die er selbst gar keine Kontrolle hat. Schließlich wäre es mit relativ geringem Aufwand möglich, mittels eines Man-in-the-Middle-Angriffs (MITM) eine falsche Identität vorzutäuschen und die Trireme-Policy auszutricksen. Trireme greift hier wieder auf ein ebenso einfaches wie geniales Konzept zurück: Wird eine Verbindung zu einer Anwendung aufgebaut, so schickt diese ihre Identität, also das Set an vordefinierten Attributen, an die anfragende Anwendung. Dies passiert bereits beim TCP-Handshake. Die Attribute werden hierbei einfach als zusätzliche Payload zu den SYN/SYN-ACK/ACK-Paketen übertragen. Diese sind natürlich kryptografisch signiert, sodass diese auf Empfängerseite anhand dieser Signatur verifiziert werden können. Hierfür lässt sich entweder ein preshared Key (PSK) oder ein X.509-Zertifikat einsetzen.

Der PSK wird als Kubernetes-Secret allen Knoten eines Clusters zur Verfügung gestellt. Kommt hingegen die PKI-Variante zum Einsatz, muss neben dem Zertifikat der Certificate Authority (CA) auch der private Schlüssel des eingesetzten Zertifikates auf den Cluster-Knoten vorliegen. Der öffentliche Schlüssel hingegen kann als Teil der Node-Ojekte über die Kubernetes-API zur Verfügung gestellt werden. Der private Schlüssel dient dann zum Signieren des Attribute-Sets, das sich mit Hilfe des öffentlichen Schlüssels verifizieren lässt. Wir empfehlen den Einsatz der PKI-Variante. Da der PSK als Kubernetes-Secret innerhalb der etcd-Datenbank gespeichert wird, bringt diese Variante einige potenzielle Unsicherheiten mit sich.