Ansible Tower / AWX / Automation controller Security
Grundlegende Informationen
Ansible Tower oder seine Open-Source-Version AWX ist auch als Benutzeroberfläche, Dashboard und REST-API von Ansible bekannt. Mit rollenbasierter Zugriffskontrolle, Jobplanung und grafischem Bestandsmanagement können Sie Ihre Ansible-Infrastruktur über eine moderne Benutzeroberfläche verwalten. Towers REST-API und Befehlszeilenschnittstelle machen es einfach, sie in aktuelle Tools und Workflows zu integrieren.
Automation Controller ist eine neuere Version von Ansible Tower mit mehr Funktionen.
Unterschiede
Laut diesem sind die Hauptunterschiede zwischen Ansible Tower und AWX der erhaltene Support und dass Ansible Tower zusätzliche Funktionen wie rollenbasierte Zugriffskontrolle, Unterstützung für benutzerdefinierte APIs und benutzerdefinierte Workflows bietet.
Technologie-Stack
Webinterface: Dies ist die grafische Benutzeroberfläche, über die Benutzer Bestände, Anmeldeinformationen, Vorlagen und Jobs verwalten können. Es ist so konzipiert, dass es intuitiv ist und Visualisierungen bietet, um das Verständnis des Zustands und der Ergebnisse Ihrer Automatisierungsjobs zu erleichtern.
REST-API: Alles, was Sie im Webinterface tun können, können Sie auch über die REST-API tun. Dies bedeutet, dass Sie AWX/Tower mit anderen Systemen integrieren oder Aktionen skripten können, die Sie normalerweise in der Benutzeroberfläche ausführen würden.
Datenbank: AWX/Tower verwendet eine Datenbank (typischerweise PostgreSQL), um die Konfiguration, Jobergebnisse und andere erforderliche Betriebsdaten zu speichern.
RabbitMQ: Dies ist das Nachrichtensystem, das von AWX/Tower verwendet wird, um zwischen den verschiedenen Komponenten zu kommunizieren, insbesondere zwischen dem Webservice und den Task-Runnern.
Redis: Redis dient als Cache und Backend für die Task-Warteschlange.
Logische Komponenten
Bestände: Ein Bestand ist eine Sammlung von Hosts (oder Knoten), gegen die Jobs (Ansible-Playbooks) ausgeführt werden können. AWX/Tower ermöglicht es Ihnen, Ihre Bestände zu definieren und zu gruppieren und unterstützt auch dynamische Bestände, die Hostlisten von anderen Systemen wie AWS, Azure usw. abrufen können.
Projekte: Ein Projekt ist im Wesentlichen eine Sammlung von Ansible-Playbooks, die aus einem Versionskontrollsystem (wie Git) stammen, um die neuesten Playbooks bei Bedarf abzurufen.
Vorlagen: Jobvorlagen definieren, wie ein bestimmtes Playbook ausgeführt wird, und geben die Bestandsaufnahme, Anmeldeinformationen und andere Parameter für den Job an.
Anmeldeinformationen: AWX/Tower bietet eine sichere Möglichkeit, Geheimnisse wie SSH-Schlüssel, Passwörter und API-Token zu verwalten und zu speichern. Diese Anmeldeinformationen können mit Jobvorlagen verknüpft werden, damit Playbooks den erforderlichen Zugriff haben, wenn sie ausgeführt werden.
Task-Engine: Hier passiert die Magie. Die Task-Engine basiert auf Ansible und ist dafür verantwortlich, die Playbooks auszuführen. Jobs werden an die Task-Engine übergeben, die dann die Ansible-Playbooks gegen den festgelegten Bestand unter Verwendung der angegebenen Anmeldeinformationen ausführt.
Scheduler und Rückrufe: Dies sind erweiterte Funktionen in AWX/Tower, die es ermöglichen, Jobs zu planen, um zu bestimmten Zeiten ausgeführt zu werden oder durch externe Ereignisse ausgelöst zu werden.
Benachrichtigungen: AWX/Tower kann Benachrichtigungen basierend auf dem Erfolg oder dem Misserfolg von Jobs senden. Es unterstützt verschiedene Arten von Benachrichtigungen wie E-Mails, Slack-Nachrichten, Webhooks usw.
Ansible-Playbooks: Ansible-Playbooks sind Konfigurations-, Bereitstellungs- und Orchestrierungstools. Sie beschreiben den gewünschten Zustand von Systemen auf automatisierte, wiederholbare Weise. In YAML geschrieben, verwenden Playbooks Ansibles deklarative Automatisierungssprache, um Konfigurationen, Aufgaben und Schritte zu beschreiben, die ausgeführt werden müssen.
Ablauf der Jobausführung
Benutzerinteraktion: Ein Benutzer kann mit AWX/Tower entweder über das Webinterface oder die REST-API interagieren. Diese bieten einen Front-End-Zugriff auf alle von AWX/Tower angebotenen Funktionen.
Job-Initiierung:
Der Benutzer initiiert über das Webinterface oder die API einen Job basierend auf einer Jobvorlage.
Die Jobvorlage enthält Verweise auf den Bestand, das Projekt (das Playbook enthält) und die Anmeldeinformationen.
Bei der Job-Initiierung wird eine Anfrage an das AWX/Tower-Backend gesendet, um den Job zur Ausführung in die Warteschlange zu stellen.
Job-Warteschlange:
RabbitMQ übernimmt die Kommunikation zwischen der Webkomponente und den Task-Runnern. Sobald ein Job initiiert wird, wird über RabbitMQ eine Nachricht an die Task-Engine gesendet.
Redis fungiert als Backend für die Task-Warteschlange und verwaltet wartende Jobs, die auf die Ausführung warten.
Job-Ausführung:
Die Task-Engine nimmt den in die Warteschlange gestellten Job auf. Sie ruft die erforderlichen Informationen aus der Datenbank zu dem mit dem Job verknüpften Playbook, Bestand und Anmeldeinformationen ab.
Mit dem abgerufenen Ansible-Playbook aus dem zugehörigen Projekt führt die Task-Engine das Playbook gegen die angegebenen Bestandsknoten unter Verwendung der bereitgestellten Anmeldeinformationen aus.
Während das Playbook ausgeführt wird, werden dessen Ausführungsergebnisse (Protokolle, Fakten usw.) erfasst und in der Datenbank gespeichert.
Job-Ergebnisse:
Sobald das Playbook fertig ausgeführt ist, werden die Ergebnisse (Erfolg, Fehler, Protokolle) in der Datenbank gespeichert.
Benutzer können die Ergebnisse dann über das Webinterface anzeigen oder über die REST-API abfragen.
Basierend auf den Jobergebnissen können Benachrichtigungen versendet werden, um Benutzer oder externe Systeme über den Status des Jobs zu informieren. Benachrichtigungen können E-Mails, Slack-Nachrichten, Webhooks usw. sein.
Integration externer Systeme:
Bestände können dynamisch aus externen Systemen bezogen werden, sodass AWX/Tower Hosts aus Quellen wie AWS, Azure, VMware und mehr einbeziehen kann.
Projekte (Playbooks) können aus Versionskontrollsystemen abgerufen werden, um die Verwendung aktueller Playbooks während der Jobausführung sicherzustellen.
Scheduler und Rückrufe können verwendet werden, um mit anderen Systemen oder Tools zu integrieren, sodass AWX/Tower auf externe Auslöser reagieren oder Jobs zu vorbestimmten Zeiten ausführen kann.
AWX-Laborerstellung für Tests
Gemäß der Dokumentation ist es möglich, Docker-Compose zu verwenden, um AWX auszuführen:
RBAC
Unterstützte Rollen
Die privilegierteste Rolle wird als Systemadministrator bezeichnet. Jeder mit dieser Rolle kann alles ändern.
Bei einer White-Box-Sicherheitsüberprüfung benötigen Sie die Rolle des Systemprüfers, der es ermöglicht, alle Systemdaten anzuzeigen, aber keine Änderungen vornehmen kann. Eine andere Option wäre die Organisationsprüferrolle, aber es wäre besser, die andere zu erhalten.
Last updated