Netzwerkautomatisierung mit Ansible und AWX
Die Rakete zünden
Veröffentlicht in Ausgabe 09/2021 - PRAXIS
Während in vielen Netzwerken noch fehleranfällige, repetitive Handarbeit auf der CLI angesagt ist, gehen moderne Administratoren einen anderen Weg und nutzen Skripte. Auf den ersten Blick bietet manuelles Scripting maximale Flexibilität, jedoch erfüllt die Automatisierung keinen Selbstzweck. Sie soll die Effizienz und Konsistenz steigern, um Freiräume für andere Innovationen zu schaffen. Gleichzeitig gilt es aber auch, die Sicherheit zu gewährleisten.
Um diese Aspekte bei der Netzwerkautomatisierung umzusetzen, stehen Konfigurationsmanagementwerkzeuge zur Verfügung. Da auf vielen aktiven Netzwerkkom- ponenten wie Routern und Switches keine Möglichkeiten der Installation von Agenten zur Steuerung solcher Werkzeuge bestehen, bieten sich agentenlose Tools an. Optimal kann eine solche Software nicht nur aktive Netzwerkkomponenten, sondern auch Linux- und Windows-Serversysteme. Hier kommt das Open-Source-Tool Ansible [1] ins Spiel.
Zwei Tools lösen Ansibles Probleme
Jedoch bringt das native CLI-Tool Ansible einige Herausforderungen mit sich. Eine hiervon stellt das Rechtemanagement dar. Zum einen stellt sich die Frage, wie das Hinterlegen von Credentials für die aktiven Netzwerkkomponenten erfolgen soll: Für Service-Accounts mit Vollzugriff auf Switches, Router und Firewalls muss sichergestellt sein, dass Nutzer mit ansonsten eingeschränkten Rechten, wie Junior-Admins oder Auditoren, keine Privilegien-Eskalation durchführen können, nur weil sie Zugriff auf Ansible benötigen. Zusätzlich besteht die Notwendigkeit einer sicheren und verschlüsselten Ablage der Credentials.
Während in vielen Netzwerken noch fehleranfällige, repetitive Handarbeit auf der CLI angesagt ist, gehen moderne Administratoren einen anderen Weg und nutzen Skripte. Auf den ersten Blick bietet manuelles Scripting maximale Flexibilität, jedoch erfüllt die Automatisierung keinen Selbstzweck. Sie soll die Effizienz und Konsistenz steigern, um Freiräume für andere Innovationen zu schaffen. Gleichzeitig gilt es aber auch, die Sicherheit zu gewährleisten.
Um diese Aspekte bei der Netzwerkautomatisierung umzusetzen, stehen Konfigurationsmanagementwerkzeuge zur Verfügung. Da auf vielen aktiven Netzwerkkom- ponenten wie Routern und Switches keine Möglichkeiten der Installation von Agenten zur Steuerung solcher Werkzeuge bestehen, bieten sich agentenlose Tools an. Optimal kann eine solche Software nicht nur aktive Netzwerkkomponenten, sondern auch Linux- und Windows-Serversysteme. Hier kommt das Open-Source-Tool Ansible [1] ins Spiel.
Zwei Tools lösen Ansibles Probleme
Jedoch bringt das native CLI-Tool Ansible einige Herausforderungen mit sich. Eine hiervon stellt das Rechtemanagement dar. Zum einen stellt sich die Frage, wie das Hinterlegen von Credentials für die aktiven Netzwerkkomponenten erfolgen soll: Für Service-Accounts mit Vollzugriff auf Switches, Router und Firewalls muss sichergestellt sein, dass Nutzer mit ansonsten eingeschränkten Rechten, wie Junior-Admins oder Auditoren, keine Privilegien-Eskalation durchführen können, nur weil sie Zugriff auf Ansible benötigen. Zusätzlich besteht die Notwendigkeit einer sicheren und verschlüsselten Ablage der Credentials.
Eine weitere Herausforderung stellt ein zentrales und auditierbares Log dar. Gerade bei Konfigurationsmanagement-Tools, mit denen in kurzer Zeit Massenkonfigurationen erfolgen, muss rückverfolgbar sein, wer zu welcher Zeit welchen Change auf welchen Komponenten durchgeführt hat. Dies erleichtert auch ein eventuell notwendiges Troubleshooting. Auch eine Möglichkeit, vorbereitete Changes zeitgesteuert auszuführen und im Nachgang Benachrichtigungen über den Ausführungsstatus an die Systemverantwortlichen zu versenden, bringt viele Vorteile mit sich. Dies erhöht die Flexibilität immens. Eine übersichtliche Web-basierte GUI mit Rechte- und Rollenmanagement wäre ebenfalls wünschenswert.
Um den vorgenannten Herausforderungen zu begegnen, gibt es mindestens zwei Möglichkeiten: Wer auf einen Herstellersupport baut, kann auf Red Hats "Ansible Tower" [2] setzen. Eine Alternative stellt das von Red Hat im August 2017 unter eine Apache-2.0-Lizenz gestellte Projekt AWX [3] dar, das im Zentrum dieses Artikels steht. Es ist das vorgelagerte Community-Projekt zu Ansible Tower. Beide Tools bilden eine auf Ansible aufbauende Web-basierte GUI inklusive einer Task Engine und zugehöriger REST-API. Red Hat nutzt für Tower stabile AWX-Versionen, härtet diese für den Enterprise-Einsatz und liefert entsprechenden Support. Die Versionierung der beiden Anwendungen unterscheidet sich ebenfalls, da AWX einen kürzeren Release-Zyklus pflegt. Red Hat empfiehlt für den produktiven Einsatz Ansible Tower.
AWX einspielen
Bevor wir loslegen, sollten Sie sicherstellen, dass Ihr Zielsystem die Hardwarevoraussetzungen erfüllt. Dies sind 4 GByte RAM, zwei CPU-Kerne sowie 20 GByte freier HDD/SSD-Speicher. Diese Werte sind jedoch vom Einsatzszenario abhängig und stellen nur die untere Grenze dar. Softwareseitig bedarf es Ansible in einer Version größer 2.8, GNU Make, Git in mindestens der Version 1.8.4 und Python größer Version 3.6. Für den Fall des Einsatzes einer externen Datenbank muss noch ein PostgreSQL größer Version 10 bereitstehen.
Je nach Installationsart (Docker, Open-Shift oder Kubernetes) kommen außerdem noch weitere Pakete für den Betrieb der Container zur Anwendung. In der dargestellten Docker-Variante betrifft dies Docker, Docker-Compose sowie das Docker-Python-Modul.
Die gemeinsame Installation der drei zuvor genannten Docker-Pakete in Kombination mit Ansible und der Ansible-Tower-CLI auf Ubuntu 20.04 haben wir im Listing-Kasten dargestellt. Darin erfolgt im Anschluss der Wechsel in das "/opt/"-Verzeichnis, gefolgt vom Klonen von AWX 17.0.1 aus dem GitHub Repository.
Um einen der wichtigsten Schritte der Installation durchzuführen, wechseln wir in das Verzeichnis "awx/installer/" und bearbeiten die Datei "inventory". In dieser finden sich Kennwörter wieder, die Credentials für die Postgres-Datenbank, Referenzen zu Webserver- und CA-Zertifikaten sowie auch Zugriffe auf lokale Verzeichnisse. Auch eine Definition des Docker-Subnetzes kann hier erfolgen. Nachdem wir diese auf unsere Bedürfnisse angepasst haben, führen wir das Playbook "install.yml" im "installer"-Verzeichnis mit der zuvor angepassten Inventardatei aus, um die Docker-Container zu erstellen. Damit der Docker-Daemon nach einem Neustart automatisiert hochfährt, aktivieren Sie den Dienst über
systemctl enable docker.Alternativ zu dieser Installation über das Ansible-Playbook zum Erstellen von Docker-Containern können Sie über eine entsprechende Vorbereitung sowie anschließende Parametrisierung der Inventardatei und Nachbereitung auch eine Installation für Red Hats OpenShift durchführen. Gleiches gilt auch für Kubernetes – alle drei Varianten sind in GitHub beschrieben, folgen Sie erneut dem Link-Code [2].
Nach erfolgreicher Installation als Docker-Container stehen uns vier Container zur Verfügung: ein Nginx-Webserver, eine PostgreSQL-Datenbank, die NoSQL-Datenbank Redis sowie ein Task-Manager. Die Vorbereitung der Docker-Container für einen Autostart haben wir bereits bei der Installation erledigt.
Listing : Installation AWX unter Ubuntu 20.04 Server
sudo apt update
sudo apt install ansible ansible-tower-cli docker docker-compose python3-docker
cd /opt/
sudo git clone -b 17.0.1 https://github.com/ansible/awx.git
cd awx/installer
sudo vi inventory
#Setzen nutzerspezifischer Einstellungen
sudo ansible-playbook -i inventory install.yml
systemctl enable docker
Grundkonfiguration erledigen
Nachdem die Container bereitstehen, kann der erste Aufruf des Webservers über den parametrisierten Port (beispielsweise TCP/80 oder TCP/443) und mit den entsprechenden Credentials aus der Inventory-Datei erfolgen. Nach erfolgreichem Log-in begrüßt uns das in Bild 1 dargestellte Dashboard von AWX. Darin erhalten Sie einen ersten groben Überblick über das Gesamtsystem. Darunter die Anzahl der eingerichteten Hosts – also der Zielsysteme –, die Anzahl der Inventories sowie der Projekte. Zusätzlich finden Sie hier einen Überblick über den Erfolgsstatus der aktiven Jobs, den Sie über grüne oder rote Linien im unteren Bereich identifizieren.
Im linken Bereich steht Ihnen eine Menüstruktur zur Verfügung, die unter anderem Verknüpfungen zu Jobs, Credentials, Projekten, Inventaren, Hosts, Or- ganisationen, Usern und Teams enthält. Im ersten Schritt müssen Sie hier eine Organisation anlegen. Diese bildet sozusagen das Top-Level-Objekt. Der Organisation können Sie diverse Objekte wie Inventardaten, Teams, Projekte und Jobs zuweisen.
IT-Administrator Sonderheft Automatisierung
Diesen Artikel und 180 Seiten weitere praxisnahe Beiträge liefert unser neues Sonderheft "Automatisierung – Abläufe programmieren, manuelle Arbeit reduzieren". Das zweite Sonderheft des Jahres 2021 zeigt IT-Verantwortlichen Strategien und Technologien auf, um die IT und ihre Abläufe von der Handarbeit zu befreien.
Dazu widmet sich das Autorenteam zunächst dem Scripting mit PowerShell, BASH und Python – von den ersten Schritten über Best Practices bis hin zur Sicherheit innerhalb der Skripte. Anschließend wendet sich das Sonderheft dem umfangreichen Park an Automatisierungswerkzeugen von Ansible, Puppet und Chef bis hin zu Terraform und den Automatisierungsframeworks von VMware und Red Hat zu. Auf den ersten beiden Abschnitten aufbauend, setzen die Autoren dann im dritten Teil des Sonderhefts konkrete Automatisierungsanforderungen um. Dabei kümmern wir uns um Windows-Server und -Clients, um VMware- und Citrix-Umgebungen und um Netzwerkomponenten.Das Sonderheft ist ab Oktober verfügbar und kostet für Abonnenten des IT-Administrator 24,90 Euro, für Nicht-Abonnenten werden 29,90 Euro fällig.
Im Nachgang zu den Organisationen definieren Sie sogenannte Teams. Diese erlauben, Benutzer zu gruppieren und darauf aufbauend entsprechende Rechte zuzuweisen. Die einfachste, aber auch am wenigsten flexible Variante für den Zugriff auf AWX stellen manuell angelegte Benutzer dar. Benutzer können vom Typ normaler Nutzer, Systemauditor oder Systemadministrator sein.
Für ein flexibleres Benutzermodell gibt es vielfältige Möglichkeiten auf der Authentifizierungsebene. Neben den klassischen Varianten für Authentifizierung, Autorisierung und Abrechnung (AAA) wie RADIUS und TACACS+ oder LDAP stehen auch SAML-Schnittstellen sowie die Anbindung an das Azure AD, GitHub oder Google OAuth2 zur Verfügung. Hierüber sind dann gemäß Attributs-Mappings Organisations- und Teamzuweisungen möglich, an die wiederum Berechtigungen gebunden sind. Somit ist beispielsweise die Einteilung eines Teams in Junioradministratoren über LDAP-Gruppenmitgliedschaften möglich. Hier lassen sich zudem eingeschränkte Rechte hinterlegen, wie zum Beispiel auf Access-Switche.
Dahingegen könnten Sie ein Mapping für Senioradministratoren, die auf Core-Komponenten des Netzwerks zugreifen dürfen, einrichten. Für Nutzer von Drittanbieter-Authentifizierungslösungen wie LDAP erfolgt ein automatisiertes Anlegen des Users beim ersten Login. Neben dem entsprechenden Nutzer erscheint dann ein Kästchen mit einer Anmerkung, dass dieser aufgrund des LDAP-Logins angelegt wurde. Beim Einsatz von LDAPS sollten Sie beachten, dass die erforderlichen CA-Zertifikate für die LDAPS-Server auf den Docker-Hosts bereitstehen.
Credentials als Schlüssel zur Wahrheit
Eines der häufigsten Probleme von Automatisierungslösungen und eigenen Skripten ist die sichere Hinterlegung der Credentials. Damit die Möglichkeit eines Zugriffs auf einzelne Zielkomponenten wie Router und Switches oder Server in den Projekten möglich ist, besteht die Notwendigkeit der Hinterlegung dieser Anmeldedaten.
Diese weisen je nach Typ Eignungen für unterschiedliche Zielsysteme auf, Bild 2 zeigt den Typ "Network". Für Linux-Server und das network_cli-Modul nutzen wir den Credential-Typ "Machine". Um zu klären, welcher Credential-Typ für das jeweilige Modul zur Anwendung kommen kann, sollten Sie die entsprechende Dokumentation konsultieren. Neben Username und Kennwort besteht unter anderem auch die Möglichkeit, einen Private Key inklusive der zugehörigen Passphrase zu hinterlegen, falls bei Ihnen eine Public-Key-Authentifizierung zum Einsatz kommen soll.
Die Ablage der Credentials in der Datenbank erfolgt verschlüsselt im Electronic-Code-Book-Verfahren mit AES-128 als Block Cipher auf Basis des Secret Keys, der vor dem Erzeugen der Docker-Container in der Inventardatei hinterlegt wurde. Über den Parameter "Authorize" kann auch ein Wechsel in den privilegierten Modus (bekannt auch als "enable"-Modus) stattfinden, falls das zugehörige Authorize-Passwort hinterlegt ist.
Fazit
AWX bietet eine vielfältig einsetzbare Automatisierung. Es behandelt einige Herausforderungen des klassisch CLI-basierten Ansible. Im zweiten Workshopteil invetarisieren wir unsere Geräte und starten Automatisierungsjobs.
(jp)
Link-Codes
[1] Ansible: https://github.com/ansible/ansible
[2] Ansible Tower: https://www.microsoft.com/en-us/windowsforbusiness/windows-autopilot/
[3] AWX: https://github.com/ansible/awx/