Whitelisting von IP-Adressen in Kubernetes: Was wir gelernt haben

Linode Systems Engineer Jon "jfred" Frederickson teilt seine Erfahrung mit dem Ausbau der IP-Whitelisting-Funktion für den Betrieb von Kubernetes auf Linode.

Als das Linode Engineering-Team unsere Kubernetes-Funktionen ausbaute, stießen wir wie erwartet auf viele Hindernisse. Eine Herausforderung ergab sich, die wir nicht erwartet hatten: Wie können Anwendungen, die in Kubernetes laufen, auf der bereits vorhandenen Infrastruktur auf die Whitelist gesetzt werden?

Hier bei Linode betreiben wir mehrere interne Anwendungen. Mit Hilfe von Firewall-Regeln sind diese Anwendungen nur für die Netzwerke und Systeme zugänglich, die sie benötigen.

Wenn Sie eine Anwendung mit einer eigenen Datenbank haben, muss diese Datenbank wahrscheinlich nur von Instanzen dieser Anwendung erreichbar sein. Wenn beide in einem Kubernetes-Cluster laufen, ist das ganz einfach; mit NetworkPolicies können Sie das sperren. Aber wenn ein Dienst außerhalb des Clusters läuft, wird die Sache immer komplizierter.

Wir hatten bereits eine gewisse Automatisierung rund um das IP-Whitelisting eingeführt, aber Kubernetes-Cluster haben das Potenzial, dynamischer zu sein als alles andere in unserer bisherigen Infrastruktur. Aus diesem Grund mussten wir sicherstellen, dass wir unsere Whitelists auf dem neuesten Stand halten konnten, wenn Knoten zu Clustern hinzugefügt und aus ihnen entfernt wurden. Wir fanden heraus, dass dies ein ziemlich häufiges Problem für jeden sein muss, der Kubernetes in die bestehende Infrastruktur einführt, aber wir haben keine anderen öffentlichen Lösungen für das Problem gefunden.

Das Problem

Meine Herausforderung: Wenn ich alle Knoten in einem bestimmten Cluster auf einem Server außerhalb des Clusters auf die Whitelist setzen wollte, wie würde meine ideale Konfiguration aussehen?

Ohne Kubernetes-fähige Tools wäre ich gezwungen, die einzelnen IP-Adressen von Clusterknoten manuell auf die Whitelist zu setzen. Dies ist nicht nur zeitaufwendig, sondern öffnet menschlichem Versagen auch Tür und Tor, was dem Entwicklungsprozess eher nicht förderlich ist.

Die Lösung

In den nächsten Wochen habe ich dann eine Lösung entwickelt, die das Whitelisting eines Kubernetes-Clusters (meist) so einfach macht wie das manuelle Whitelisting einer einzelnen IP.

Wir verwenden Salt zur Verwaltung unserer Infrastruktur, und wir hatten bereits eine Salt-Formel zur Verwaltung von Firewall-Regeln. Unter den mit Salt ausgerollten Infrastrukturen hatten wir bereits Mechanismen, um beim Erstellen von Whitelists Systeme einer bestimmten Klasse zu finden, also suchten wir nach etwas Ähnlichem für unsere Kubernetes-Cluster.

Salt ist extrem flexibel und macht das Schreiben von kundenspezifischen Modulen einfach. Beispielsweise verwendet unsere iptables-Formel eine, um Regeln aus der Per-Node-Konfiguration von Salt zu generieren ("Pillar"-Daten). Wir tun dies, indem wir aus einer Liste im Salt-Pillar eine Regel nach der anderen abarbeiten. Das ergibt eine lange Zeichenkette, die zugegebenermaßen ein wenig hässlich aussieht. Glücklicherweise ist das iptables-Regelformat so stabil, dass es am Ende doch ziemlich gut funktioniert. Hier ein Ausschnitt aus dem, wie das aussieht:

Dank der flexiblen API von Kubernetes war diese Integration konzeptionell nicht so schwierig. Im Wesentlichen haben wir einen neuen Regeltyp für K8s-Cluster hinzugefügt: Wenn die Formel auf eine Regel dieses Typs trifft, kontaktiert sie diesen Cluster, um die IPs seiner Knoten zu holen, sie lokal zwischenzuspeichern und iptables-Regeln für jede IP einzufügen. Das Caching soll sicherstellen, dass intermittierende Netzwerkausfälle keine Probleme verursachen. Und so sieht das aus:

Wie geht es weiter?

Letztendlich möchte ich die gesamte Formel Open Source machen, um die Kapazität des Tools mit Hilfe der Linode Community noch weiter auszubauen.

Der nächste Schritt ist jedoch, diese Regeln automatisch zu aktualisieren, wenn neue Knoten einem Cluster beitreten und ihn verlassen. Das Ziel ist, dass das dauerhafte Whitelisting eines Clusters so einfach ist wie das Whitelisting einer einzelnen IP, aber wir sind noch nicht ganz am Ziel.

Wie die Formel jetzt vorliegt, werden neue Knoten nur dann hinzugefügt, wenn die Firewall-Konfiguration angewendet wird, aber nicht automatisch. Dies ist kein allzu großes Problem, da wir dies umgehen können, indem wir die Firewall-Konfiguration regelmäßig aktualisieren.

Ich möchte jedoch einen Weg finden, um sie reaktionsfähiger zu machen. Mein vorgesehener Mechanismus würde auf dieses Event warten (die Erstellung eines neuen Node Objekts in Kubernetes) und ein Update auslösen (wahrscheinlich über den Salt Event Bus). Im Idealfall sind dazu neben der Konfiguration einer Regel für die Kubernetes-Firewall keine manuellen Schritte erforderlich. Vielleicht können Sie uns helfen, sobald wir die Formel einmal Open Source gemacht haben!

Im Moment bin ich sehr zufrieden mit dem, was wir geschaffen haben, und glaube, dass es ein Gewinn für Linode-Benutzer sein wird, die mit Kubernetes experimentieren.

Vielen Dank, dass Sie sich über den System Engineering Prozess von Linode schlau gemacht haben. Bitte lassen Sie es mich im Kommentarbereich wissen, wenn Sie Fragen zu unserem Vorgehen haben.

Interessiert an Kubernetes auf Linode?

Unser Team ist stolz darauf, die Beta-Version der Linode Kubernetes Engine (LKE) vorzustellen - eine vollständig verwaltete Container-Orchestrierungs-Engine zur Bereitstellung und Verwaltung von containerisierten Anwendungen und Workloads.

Wir brauchen aber Ihr Feedback. Bitte melden Sie sich hier für die LKE-Beta an, um es auszuprobieren und kostenlose Linode-Swag zu verdienen.