Netzwerkautomatisierung

06 Sep. Netzwerkautomatisierung

Sommer war, es war heiß. Was gibt es da sonst zu tun, als über Netzwerkautomatisierung nachzudenken?

Die cycan Vision: ein zentrales Management für

• die Appliance selbst,
• das Monitoring mit Checkmk,
• die Dokumentation in NetBox.

cycan-Infra-Vision

Bevor ich auf meinen Ansatz eingehe – Spoiler: Ansible – ein paar grundsätzliche Überlegungen. Um es greifbarer zu machen und es für mich leicht ist, nehmen wir eine Fortigate als Device für meine generellen Überlegungen.

Sorry vorab: das ist ein wenig bla und erklärt teilweise gut bekannte Dinge. Es ist der Einstieg.

Herstellerlösungen – am Beispiel FortiManager

Wenn es ausschließlich um Firewall-Management geht, gewinnt meiner Meinung nach fast immer die Herstellerlösung (Surprise!).

FortiManager bringt sehr viel fertige Funktionalität mit, entspricht den gewohnten Firewall-Admin-Workflows (jeder Firewall-Admin kann damit gurndsätzlich umgehen) und liefert auch Compliance- und Statusinformationen. Policies, Templates und Konfigurationen zeigen nicht nur, was gewünscht ist, sondern auch, ob dieser Zustand tatsächlich erreicht wurde.

Das alles selbst nachzubauen wäre ein erheblicher Aufwand.

Natürlich kostet FortiManager Lizenzgebühren. Die Funktionalität ist das Geld durchaus wert – und Eigenentwicklungen sind schließlich auch nicht „gratis“.

Kurz gesagt: Wenn es NUR um die Verwaltung der Appliance geht, bitte um entsprechenden Münzeinwurf.

NetBox

Der geneigte Leser wird vermutlich bald meine gewisse Leidenschaft für NetBox kennenlernen. Auch auf Basis der Daten in NetBox lässt sich sehr viel automatisieren.

Mein Problem dabei: Ich bin kein Entwickler. (Verdammte Kreative, nahezu Hippies.)

Und noch wichtiger: Ich halte wenig davon, alles selbst zu programmieren, nur weil es möglich wäre. Es passt einfach nicht ganz zu meinem Ansatz bezüglich Verwaltung der Infrastruktur – das soll aber bitte niemanden davon abhalten.

Anmerkung: Andere Prozesse lassen sich dann ideal in der Netbox automatisieren, aber imho nicht die Grundstruktur.

Warum Ansible?

Ansible werde ich hier nicht grundsätzlich erklären. Meine Beweggründe waren relativ simpel:

Es ist ausgereift, weit verbreitet und gut dokumentiert. Es unterstützt meine bevorzugten Systeme – Docker, Checkmk, NetBox, Fortinet, … – und basiert auf YAML.

Ich bin kein Programmierer, aber YAML verstehe sogar ich halbwegs. Und in einem größeren IT-Team können deutlich mehr Leute eine vernünftig geschriebene Ansible-Rolle nachvollziehen als irgendein selbst entwickeltes Framework.

Dazu kommen Git, Versionskontrolle und Reviews.

Und natürlich KI.

KI kann mit Ansible ausgesprochen gut umgehen. Das verleitet durchaus dazu, Rollen zu erzeugen, die irgendwann nur noch die KI versteht.

Würde ich natürlich nie machen.

Hmm.

Hmm.

Abseits davon ist KI gerade für Reviews, Fehlersuche und Vereinfachungen ziemlich praktisch.

Arbeitsweise & GUI

„Die richtigen Admins arbeiten nur in der CLI.“ So ein Unsinn, natürlich will man wenn möglich eine GUI haben, sobald es etwas komplexer wird. Im Falle von ansible gibt es mal den Ansible Tower / Red Hat Ansible Automation Platform, Semaphore UI oder AWX. Und ich gehe jetzt mal nicht auf Lizenzen (ersteres ist wohl mehr als eine reine UI und mit höheren Kosten verbunden) ein – einfach weil ich keine Ahnung habe. Kommt vielleicht noch, aktuell arbeite ich tatsächlich nur mit einem Editor & GIT, führe meine Playbooks manuell aus und im Prinzip geht das mal in Ordnung.

Editor

Kurzer Schock für alle Netzwerkadmins: wir verwenden da nicht Notepad++, ich weiß das ist ein harter Schlag („This is my rifle editor. There are many like it, but this one is mine.„) Visual Studio Code verwenden. Das ist in der Kombi einfach sinnvoller.

SSH

Vielleicht auch da ein wenig mit ssh-keys, ssh-agent und ssh-tunnel beschäftigen , vor allem wenn man zB auf APIs via JumpHost sicher aber bequem zugreifen will.

GIT

Kleine Grundkompetenzen aneignen – das zahlt sich so oder so aus. Wie der beste Exchange & MS365 Admin aller Zeiten hier erklärt: https://www.msxfaq.de/code/git_fuer_admins.htm

Organisationsblick

Aus Sicht einer Organisation können natürlich noch andere Überlegungen dazukommen: weniger Abhängigkeit von einzelnen Herstellerlösungen, einheitliche Prozesse über mehrere Plattformen hinweg oder der Wunsch, nicht nur die Appliance selbst (inklusive erwähnten Monitoring/Dokumentation), sondern auch noch andere Systeme in einer gemeinsamen Automatisierung abzubilden.

Das kann strategisch durchaus sinnvoll sein. Aufwand/Nutzen bitte selbst einschätzen.

Was ist konkret mit Fortinet?

Fortinet muss man beim Thema Automatisierung via Ansible durchaus loben. API, Ansible-Unterstützung und Fortinet Developer Network sind sehr brauchbar. Auch dass man die Konfig einfach in YAML backupen kann. Das ist imho nicht selbstverständlich.

Ob ich ein komplexes Firewall-Ruleset komplett über Ansible verwalten möchte, lasse ich trotzdem offen.

Bestimmte Standards wie SNMP, NTP, Logging, Administratoren oder grundlegende Systemparameter lassen sich aber hervorragend automatisieren.

Die eigentliche Idee

Der für mich interessante Teil ist nicht, dass Ansible beliebige CLI-Befehle automatisch auf eine oder mehrere Firewalls schreiben kann.

Spannend wird es dort, wo dieselbe Information mehrfach verwendet werden kann:

Ansible Inventory
        │
        ├── Appliance konfigurieren
        ├── Checkmk konfigurieren
        └── NetBox konfigurieren

Genau hier liegt für mich der eigentliche Nutzen: Information einmal definieren und anschließend konsistent in mehreren Systemen verwenden.

Persönlicher Nebenschauplatz – Und dann wäre da noch Linux …

Ein weiterer Grund für Ansible ist meine persönliche Unzulänglichkeit bei Linux-Administration.

Für Labs brauche ich regelmäßig NetBox- oder Checkmk-Instanzen. Diese immer wieder manuell aufzubauen ist zeitaufwendig, öde und gehört nicht zu meinen besonderen Talenten.

Also habe ich auch das automatisiert:

Docker, NetBox, Checkmk, NGINX und die grundlegende Konfiguration werden mittlerweile über Ansible bereitgestellt.

Wie geht es weiter?

Auf sämtliche Alternativen zu Ansible gehe ich bewusst nicht ein.

Im nächsten Beitrag geht es stattdessen um den konkreten Aufbau:

Inventory → NetBox → Checkmk → FortiGate

und um eine Frage, die sich dabei ziemlich schnell stellt:

Welche Information gehört eigentlich wohin?