Cloud Native Networking mit Citrix ADC

Die Welt wird immer agiler – genauso wie die Softwareentwicklung. Der Wechsel von monolithischen Anwendungen hin zu Cloud-Native-Applikationen ist in vollem Gange. Und somit steigen auch die Anforderungen, die immer agiler werdende Software hochverfügbar und gesichert zu halten.

Genau hier setzt ein Application Delivery Controller (ADC) an. Doch beginnen wir erst einmal von vorn. Denn wofür steht Cloud Native? Und was ist ein ADC und warum brauche ich das?

Cloud Native

Bei Cloud Native handelt es sich um einen Ansatz, Software dynamisch und plattformunabhängig zu entwickeln. Software wird hierbei nicht wie bei typischen monolithischen Anwendungen als zusammenhängendes Element erstellt, sondern in viele einzelne Teile – sogenannte Microservices – geteilt, welche völlig unabhängig voneinander entwickelt werden. Diese Microservices wiederum kommunizieren über im Vorfeld definierte Schnittstellen.

Als Plattform für die Microservices dienen in der Regel Container. Durch das Zusammenführen der unterschiedlichen Container, was zumeist in Kubernetes Clustern erfolgt, entsteht am Ende die fertige Applikation.

Citrix Application Delivery Controller

Der Citrix ADC (ehemals Citrix Netscaler) ist eine Lösung für die Bereitstellung sowohl monolithischer als auch auf Microservices basierender Anwendungen. Als zentrale Netzwerkkomponente sorgt er zum einen für ein ausgeglichenes Load Balancing und zum anderen für die gesicherte Bereitstellung der Dienste. Folgende Aufgaben können über den ADC abgebildet werden:

• Load Balancing
• Content Switching
• Web Application Firewall (WAF)
• Bot Management
• Citrix Gateway
• Authentication, authorization and auditing (AAA)
• Reverse Proxy

Schlussendlich kümmert sich der ADC um die durchgängige und sichere Bereitstellung der Applikation – und dass über die unterschiedlichsten Plattformen hinweg. Dabei fühlt er sich im Layer 4 genauso zuhause wie im Layer 7.

Warum brauche ich das jetzt genau?

Wenn wir uns das obige Beispielbild genauer ansehen, stellen wir fest, dass als Einstiegspunkt in die hier verwendete Demoapplikation der „Front-end“-Container dient. Dahinter sind die einzelnen Dienste ebenfalls in Containern schematisch aufgeführt. Die Anzahl der verwendeten Container lässt sich anhand des Bildes nicht nennen; und auch in der Realität werden genaue Aussagen zur Menge an genutzten Containern kaum möglich sein. Vor diesem Hintergrund ist ein gleichbleibender Einstiegspunkt von zentraler Bedeutung. Dieser kann klassischerweise über Bordmittel wie Kubernetes Ingress, Nginx oder Metal LB erfolgen oder man nutzt hierfür einen ADC, was viele Vorteile gegenüber der klassischen Methode mit sich bringt:

• Definierter Weg in die Cluster
• TCP/IP-Optimierungen
• Zentral verwaltbare Sicherheitseinstellungen (Header-Security)
• Web Application Firewall (WAF)
• Bot Management
• Support für Layer 4 TCP/UDP
• Rewrite-/Responder-Richtlinien
• East-West Traffic
• etc.

Der wichtigste Mehrwert ist in der Tat der geregelte Einstieg zur Applikation. So ist es im Grunde egal, wie viele Container existieren und genutzt werden und auf welchem Kubernetes Worker sich diese gerade befinden. Die Verbindung der Clients, oder besser gesagt der User:innen , endet am ADC und erst dieser baut dann eine Verbindung zum Webserver der Applikation auf. Damit verbunden ist ein weiterer, durchaus charmanter Vorteil: Einstellungen können dort vorgenommen werden, wo sie definiert wurden. Somit können sich die Applikationsentwickler:innen auf die Erstellung ihrer Anwendung konzentrieren, während sich die Netzwerk- und/oder Sicherheitskolleg:innen sicher sein können, dass Anwendungen nur bereitgestellt werden, wenn diese mit dem definierten Standard übereinstimmen – beispielsweise in Sachen Header-Security oder in Bezug auf globale Richtlinien zur Webapplikationsfirewall.

Darüber hinaus können erweiterte Features innerhalb des Kubernetes Clusters (East-West Traffic) gesteuert werden.

• SSL/TLS Offloading
• Content based Routing (Treffen von Entscheidungen auf Content-Ebene)
• API Gateway (CRDs)
  • Authentication
  • Rate Limiting
  • Rewrite & Responder
  • Web Application Firewall (WAF)

Dadurch kann auch der Weg zwischen den Microservices (East-West Traffic) gesichert ablaufen. Die benötigte Sicherheitsstufe wird pro Container festgelegt, wodurch gewährleistet ist, dass keine Entwickelnden oder User:innen etwas sehen, was sie nicht sehen sollen. Überspitzt gesagt bedeutet das: Man ist nicht nur einmal authentifiziert und kann somit machen, was man will. Stattdessen muss man sich beim Zugriff auf bestimmte Ressourcen nochmals verifizieren. Und das alles Content-basiert – abgesichert über eine  oder eine WAF-Policy. Sofern Anwendungen noch keine aktuellen TLS-Verschlüsselungen vorsehen, können diese erzwungen werden. Über ein „SSL Security Enforcement“ wird der Datenverkehr zu den Anwendungen z. B. über TLS 1.3 oder aktuelle Ciphers gesichert.

Und wie passt das jetzt zusammen?

Im Kubernetes Cluster wird der Citrix Ingress Controller (CIC) bereitgestellt. Dies geschieht wahlweise über YAML Files oder über HELM Charts, welche über den sogenannten Citrix deployment builder zu Verfügung gestellt werden. Ist der Ingress Controller ausgerollt, hört er auf die definierten Ingress-Klassen. Sobald der CIC über eine bekannte Ingress-Klasse mitbekommt, dass ein neuer Service bereitsteht, konfiguriert er den ADC außerhalb von Kubernetes automatisch für den Ingress.

In den Citrix Docs werden die unterschiedlichen Methoden und Variationen erläutert, in denen der CIC ausgerollt werden kann. Dabei handelt es sich zusammengefasst um:

• Single-Tier
• Dual-Tier
• Service-mesh lite
• Service-mesh
• Cloud

Kurz und kompakt zusammengefasst

Über die Citrix Cloud-Native-Lösungen können Applikationen zentral, gesichert und vor allem standardisiert erreicht werden. Applikationsentwickler:innen können über die ihnen bekannten Wege (Annotations/Ingress classes/Service classes) ihre Anwendungen bereitstellen. Über die Erweiterungen der CIC oder besser der „Custom Ressource Definitions“ können dann die API-Gateway-Funktionalitäten innerhalb des Clusters genutzt werden.

Durch den standardisierten Weg über die Application Delivery Controller außerhalb des Kubernetes Clusters findet der Netzwerkverkehr wie definiert statt. Dazu werden die grundsätzlichen Einstellungen am ADC von der zuständigen Abteilung (Network/Security) festgelegt und bereitgestellt.