Warum haben wir es geschaffen?
Wir von der Rambler Group verwenden seit langem eine dreistufige Netzwerkarchitektur für Rechenzentren, in der jedes Projekt oder jede Infrastrukturkomponente in einem dedizierten VLAN lebte. Der gesamte Datenverkehr - sowohl zwischen vlans als auch zwischen Rechenzentren - wurde über Geräte auf Edge-Ebene abgewickelt.
Edge-Geräte sind teure Router, die viele verschiedene Funktionen ausführen können. Daher sind auch die darauf befindlichen Ports teuer. Im Laufe der Zeit wuchs der horizontale Datenverkehr (von Maschine zu Maschine - zum Beispiel Datenbankreplikation, Anforderungen an verschiedene Dienste usw.), und irgendwann trat das Problem der Portauslastung auf Grenzroutern auf.
Eine der Hauptfunktionen solcher Geräte ist die Verkehrsfilterung. Infolgedessen wurde es auch schwieriger, ACL zu verwalten: Sie mussten alles manuell erledigen, und die Ausführung der Aufgabe durch die angrenzende Abteilung nahm ebenfalls Zeit in Anspruch. Zusätzliche Zeit wurde für die Konfiguration von Ports auf Zugriffsebene aufgewendet. Es war notwendig, nicht nur manuelle Aktionen derselben NOCs durchzuführen, sondern auch potenzielle Sicherheitsprobleme zu identifizieren, da die Hosts ihren Standort ändern bzw. illegalen Zugriff auf die vlans anderer Personen erhalten können.
Es ist an der Zeit, etwas zu ändern, und Clos-Netzwerke oder, wie sie auch genannt werden, IP-Fabriken kamen zur Rettung.
Trotz der externen Ähnlichkeit besteht der grundlegende Unterschied zwischen dieser und der vorherigen Architektur darin, dass jedes Gerät, einschließlich der Blattebene, als Router fungiert und das Standard-Gateway für den Server Top-of-Rack ist. Somit kann der horizontale Verkehr zwischen Hosts verschiedener Projekte jetzt durch die Wirbelsäulenschicht und nicht durch die Kante verlaufen.
Darüber hinaus können wir auf derselben Wirbelsäulenebene Rechenzentren miteinander verbinden, und jetzt befinden sich nicht mehr als vier Netzwerkgeräte auf dem Pfad zwischen zwei beliebigen Servern. Edge-Geräte in dieser Architektur werden nur für die Verbindung von Telekommunikationsbetreibern benötigt und ermöglichen nur vertikalen Verkehr (zum und vom Internet).
Das Hauptmerkmal des Clos-Netzwerks ist, dass es keinen Ort gibt, an dem Sie den Datenverkehr zwischen Hosts filtern können. Daher muss diese Funktion direkt auf dem Server ausgeführt werden. Eine zentralisierte Firewall ist ein Programm, das den Datenverkehr auf dem Host selbst filtert, der Datenverkehr empfängt.
Bedarf
Die Notwendigkeit, eine zentralisierte Firewall zu implementieren, wurde von mehreren Faktoren gleichzeitig bestimmt:
- Endverbraucher und
- vorhandene Infrastruktur.
Daher waren die Anforderungen für die Anwendung wie folgt:
- Die Firewall muss in der Lage sein, Regeln auf dem Host und den virtuellen Maschinen zu erstellen. Darüber hinaus sollte sich die Liste der Regeln nicht von der Umgebung unterscheiden, in der die Firewall ausgeführt wird. Das heißt, die Regeln sind identisch.
- . , – ssh, ( Prometheus), .
- , -.
- , – .
- .
- : « , ».
Die Cloud der Rambler Group ist sehr dynamisch: Virtuelle Maschinen werden erstellt und entfernt, Server werden installiert und demontiert. Daher verwenden wir keinen Punkt-zu-Punkt-Zugriff, da unsere Infrastruktur das Konzept einer „Hostgruppe“ hat.
Hostgruppe ist ein Markup einer Gruppe von Servern, das ihre Rolle eindeutig beschreibt. Zum Beispiel news-prod-coolstream-blue.
Dies führt zu einer weiteren Anforderung: Benutzer müssen mit Entitäten auf hoher Ebene arbeiten - Hostgruppen, Projekte usw.
Idee und Umsetzung
Tulling Eine
zentralisierte Firewall ist eine große und komplexe Sache, die eine Agentenkonfiguration erfordert. Das Auffinden von Problemen kann mehr als fünf Minuten dauern. Daher wurde zusammen mit dem Agenten und dem Server ein Tool angezeigt, das dem Benutzer mitteilt, ob der Agent richtig konfiguriert ist und was behoben werden muss. Eine wichtige Voraussetzung für einen Host ist beispielsweise das Vorhandensein eines DNS-Eintrags in der Hostgruppe oder PTR. Das Tool informiert Sie über all dies und vieles mehr ( seine Funktionen werden unten beschrieben ).
Einheitliche Firewall
Wir versuchen, das folgende Prinzip einzuhalten: Die Anwendung, die die Firewall auf dem Host konfiguriert, sollte die einzige sein, um keine "blinkenden Regeln" zu erhalten. Das heißt, wenn der Server bereits über ein eigenes Anpassungstool verfügt (z. B. wenn die Regeln von einem anderen Agenten konfiguriert werden), gehört unsere Anwendung nicht dorthin. Nun, das Gegenteil funktioniert auch: Wenn es unseren Firewall-Agenten gibt, legt nur er die Regeln fest - hier ist das Prinzip der vollständigen Kontrolle.
Firewall ist kein iptables
Wie Sie wissen, ist iptables nur ein Befehlszeilenprogramm für die Arbeit mit netfilter. Um die Firewall auf verschiedene Plattformen (Windows, BSD-Systeme) zu portieren, arbeiten der Agent und der Server mit ihrem eigenen Modell. Mehr dazu weiter unten im Abschnitt "Architektur" .
Der Agent versucht nicht, logische Fehler zu beheben
Wie oben erwähnt, trifft der Agent keine Entscheidungen. Wenn Sie Port 443 schließen möchten, auf dem Ihr HTTP-Server bereits ausgeführt wird, kein Problem, schließen Sie ihn!
Die Architektur
Es ist schwierig, in der Architektur einer solchen Anwendung etwas Neues zu finden.
- Wir haben einen Agenten, der die Regeln auf dem Host konfiguriert.
- Wir haben einen Server, der benutzerdefinierte Regeln enthält.
- Wir haben eine Bibliothek und Werkzeuge.
- Wir haben einen High-Level-Resolver, der die IP-Adressen in Hostgruppen / Projekte ändert und umgekehrt. Mehr dazu weiter unten .
Die Rambler Group hat viele Hosts und noch mehr virtuelle Maschinen, und alle gehören auf die eine oder andere Weise zu einer Einheit:
- VLAN
- Netzwerk
- Projekt
- Hostgruppe.
Letzteres beschreibt die Zugehörigkeit des Hosts zum Projekt und seine Rolle. Zum Beispiel news-prod-backend-api, wobei: news - project; prod ist seine Umgebung, in diesem Fall ist es Produktion; Backend - Rolle; API ist ein beliebiges benutzerdefiniertes Tag.
Die Resolver-
Firewall arbeitet auf Netzwerk- und / oder Transportebene, und Hostgruppen und Projekte sind Entitäten auf hoher Ebene. Um "Freunde zu finden" und zu verstehen, wem der Host (oder die virtuelle Maschine) gehört, benötigen Sie daher eine Liste mit Adressen. Wir haben diese Komponente "High Level Resolver" genannt. Es ändert übergeordnete Namen in eine Reihe von Adressen (in Bezug auf den Resolver ist es "enthalten") und umgekehrt eine Adresse in den Namen der Entität ("enthält").
Bibliothek - Kern
Zur Vereinheitlichung und Vereinheitlichung einiger Komponenten erschien eine Bibliothek, die auch als Kern bezeichnet wird. Dies ist ein Datenmodell mit eigenen Controllern und Ansichten, mit denen Sie es füllen und lesen können. Dieser Ansatz vereinfacht den serverseitigen Code und den Agentencode erheblich und hilft auch dabei, die aktuellen Regeln auf dem Host mit den vom Server empfangenen Regeln zu vergleichen.
Wir haben verschiedene Quellen, um das Modell zu füllen:
- Regeldateien (zwei verschiedene Typen: vereinfacht und vollständige Beschreibung der Regel)
- vom Server empfangene Regeln
- vom Host selbst empfangene Regeln.
Agent
Agent ist keine Bindung über iptables, sondern eine unabhängige Anwendung, die mit einem Wrapper über C-Bibliotheken libiptc, libxtables arbeitet. Der Agent selbst trifft keine Entscheidungen, sondern konfiguriert nur die Regeln auf dem Host.
Die Rolle des Agenten ist minimal: Lesen Sie die Regeldateien (einschließlich der Standarddateien), rufen Sie Daten vom Server ab (sofern dieser für den Remotebetrieb konfiguriert ist), führen Sie die Regeln zu einem Satz zusammen, prüfen Sie, ob sie vom vorherigen Status abweichen, und gelten Sie, falls sie sich unterscheiden.
Eine weitere wichtige Rolle des Agenten besteht darin, den Host während der Erstinstallation oder beim Empfang einer ungültigen Antwort vom Server nicht in einen Kürbis zu verwandeln. Um dies zu vermeiden, stellen wir standardmäßig eine Reihe von Regeln im Paket bereit, z. B. ssh, Überwachung des Zugriffs usw. Wenn der Firewall-Agent einen anderen Antwortcode als den 200. Antwortcode erhält, versucht der Agent keine Aktion auszuführen und verlässt den vorherigen Status. Es schützt jedoch nicht vor logischen Fehlern. Wenn Sie den Zugriff auf die Ports 80, 443 verweigern, erledigt der Agent seine Arbeit auch dann, wenn der Webdienst auf dem Host ausgeführt wird.
Tulza
Tulza richtet sich an Systemadministratoren und Entwickler, die das Projekt verwalten. Das Ziel ist unglaublich einfach: Mit einem Klick erhalten Sie alle Daten über die Arbeit des Agenten. Das Dienstprogramm kann Ihnen Folgendes mitteilen:
- Wird der Agentendämon ausgeführt?
- Gibt es einen PTR-Datensatz für den Host?
- .
Diese Informationen reichen aus, um Probleme frühzeitig zu diagnostizieren.
Server
Server ist Anwendung + Datenbank. Die ganze Logik der Arbeit wird von ihm ausgeführt. Ein wichtiges Merkmal des Servers ist, dass er keine IP-Adressen speichert. Der Server funktioniert nur mit Objekten der obersten Ebene - Hostgruppennamen, Projektnamen usw.
Die Regeln in der Basis lauten wie folgt: Aktion: Akzeptieren Src: Projekt-B, Projekt-C Dst: Projekt-B Proto: TCP-Ports: 80, 443.
Wie versteht der Server, welche Regeln wem gegeben werden sollen? Aus den Anforderungen folgt, dass die Regeln identisch sein müssen, unabhängig davon, wo der Agent ausgeführt wird, sei es ein Host oder eine virtuelle Maschine.
Eine Anfrage von einem Agenten kommt immer mit einem Wert an den Server - einer IP-Adresse. Es ist wichtig, sich daran zu erinnern, dass jeder Agent nach den Regeln für sich selbst fragt, dh er ist das Ziel.
Berücksichtigen Sie zum besseren Verständnis des Serverbetriebs den Prozess zum Abrufen von Hostregeln, die zu einem Projekt gehören.
Der Resolver kommt zuerst ins Spiel. Seine Aufgabe besteht darin, die IP-Adresse in den Hostnamen zu ändern und dann herauszufinden, in welcher Entität dieser Host enthalten ist. HL-Resolver antwortet dem Server, dass der Host in Projekt A enthalten ist. HL-Resolver verweist auf die Datenquelle (die wir zuvor nicht erwähnt haben). Datenquelle ist eine Art Unternehmenswissensbasis über Server, Projekte, Hostgruppen usw.
Als Nächstes sucht der Server nach allen Regeln für das Projekt mit Ziel = Projektname. Da die Datenbank keine Adressen enthält, müssen wir die Projektnamen in hostenyms und dann in Adressen umbenennen, damit die Anforderung erneut über den Resolver an die Datenquelle gesendet wird. HL-Resoler gibt eine Liste von Adressen zurück, wonach der Agent eine vorgefertigte Liste von Regeln erhält.
Wenn unser Ziel ein Host mit virtuellen Maschinen ist, wird dasselbe Skript nicht nur für den Host, sondern auch für jede darauf befindliche virtuelle Maschine ausgeführt.
Das folgende Diagramm zeigt einen einfachen Fall: Der Host (Hardware oder virtuelle Maschine) empfängt die Regeln für den Host in Project-A.
Veröffentlichungen
Es ist nicht schwer zu erraten, dass Sie mit einer zentralisierten Firewall-Verwaltung auch alles zentral aufteilen können. Daher werden Releases für den Agenten und den Server schrittweise ausgeführt.
Für den Server - Blue-Green + A / B-Test
Blue-Green ist eine Bereitstellungsstrategie, an der zwei Hostgruppen beteiligt sind. Und die Umschaltung erfolgt in Portionen 1,3,5,10 ... 100%. Wenn daher Probleme mit der neuen Version auftreten, leidet nur ein kleiner Teil der Dienste.
Für einen Agenten
ähnelt Canary Canary (oder Canary Deployment) den A / B-Tests. Wir aktualisieren nur einige der Agenten und sehen uns die Metriken an. Wenn alles in Ordnung ist, nehmen wir ein weiteres größeres Stück und so weiter bis zu 100%.
Fazit
Aus diesem Grund haben wir einen Self-Service für Systemingenieure erstellt, mit dem Sie den Netzwerkzugriff von einem Punkt aus verwalten können. So haben wir:
- HTTP-API
- .