Ansible Tower / AWX / Automation Controller Sicherheit

Reading time: 11 minutes

Grundinformationen

Ansible Tower oder seine Open-Source-Version AWX ist auch bekannt als Ansible Benutzeroberfläche, Dashboard und REST API. Mit rollenbasiertem Zugriffskontrolle, Jobplanung und grafischer Inventarverwaltung können Sie Ihre Ansible-Infrastruktur über eine moderne Benutzeroberfläche verwalten. Die REST API und die Befehlszeilenschnittstelle von Tower 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 die erhaltene Unterstützung, und Ansible Tower hat zusätzliche Funktionen wie rollenbasierte Zugriffskontrolle, Unterstützung für benutzerdefinierte APIs und benutzerdefinierte Workflows.

Tech-Stack

• Weboberfläche: Dies ist die grafische Oberfläche, über die Benutzer Inventare, Anmeldeinformationen, Vorlagen und Jobs verwalten können. Sie ist so gestaltet, dass sie intuitiv ist und Visualisierungen bietet, um den Zustand und die Ergebnisse Ihrer Automatisierungsjobs zu verstehen.
• REST API: Alles, was Sie in der Weboberfläche tun können, können Sie auch über die REST API tun. Das bedeutet, dass Sie AWX/Tower mit anderen Systemen integrieren oder Aktionen skripten können, die Sie normalerweise in der Benutzeroberfläche durchführen würden.
• Datenbank: AWX/Tower verwendet eine Datenbank (typischerweise PostgreSQL), um seine Konfiguration, Jobresultate und andere notwendige Betriebsdaten zu speichern.
• RabbitMQ: Dies ist das Messaging-System, das von AWX/Tower verwendet wird, um zwischen den verschiedenen Komponenten zu kommunizieren, insbesondere zwischen dem Webdienst und den Aufgabenläufern.
• Redis: Redis dient als Cache und Backend für die Aufgabenwarteschlange.

Logische Komponenten

• Inventare: Ein Inventar ist eine Sammlung von Hosts (oder Knoten), gegen die Jobs (Ansible-Playbooks) ausgeführt werden können. AWX/Tower ermöglicht es Ihnen, Ihre Inventare zu definieren und zu gruppieren und unterstützt auch dynamische Inventare, die Hostlisten aus 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 das Inventar, 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-Tokens zu verwalten und zu speichern. Diese Anmeldeinformationen können mit Jobvorlagen verknüpft werden, sodass Playbooks beim Ausführen den notwendigen Zugriff haben.
• Aufgaben-Engine: Hier geschieht die Magie. Die Aufgaben-Engine basiert auf Ansible und ist verantwortlich für das Ausführen der Playbooks. Jobs werden an die Aufgaben-Engine übergeben, die dann die Ansible-Playbooks gegen das festgelegte Inventar mit den angegebenen Anmeldeinformationen ausführt.
• Planer und Rückrufe: Dies sind erweiterte Funktionen in AWX/Tower, die es ermöglichen, Jobs zu planen, die zu bestimmten Zeiten oder durch externe Ereignisse ausgelöst werden.
• Benachrichtigungen: AWX/Tower kann Benachrichtigungen basierend auf dem Erfolg oder 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 Ansible's deklarative Automatisierungssprache, um Konfigurationen, Aufgaben und Schritte zu beschreiben, die ausgeführt werden müssen.

Jobausführungsfluss

1. Benutzerinteraktion: Ein Benutzer kann mit AWX/Tower entweder über die Weboberfläche oder die REST API interagieren. Diese bieten Front-End-Zugriff auf alle von AWX/Tower angebotenen Funktionen.
2. Jobinitiierung:

• Der Benutzer initiiert über die Weboberfläche oder API einen Job basierend auf einer Jobvorlage.
• Die Jobvorlage enthält Verweise auf das Inventar, Projekt (das das Playbook enthält) und Anmeldeinformationen.
• Bei der Jobinitiierung wird eine Anfrage an das AWX/Tower-Backend gesendet, um den Job zur Ausführung in die Warteschlange zu stellen.

3. Jobwarteschlange:

• RabbitMQ verwaltet die Nachrichten zwischen der Webkomponente und den Aufgabenläufern. Sobald ein Job initiiert wird, wird eine Nachricht an die Aufgaben-Engine über RabbitMQ gesendet.
• Redis fungiert als Backend für die Aufgabenwarteschlange und verwaltet die in der Warteschlange stehenden Jobs, die auf die Ausführung warten.

4. Jobausführung:

• Die Aufgaben-Engine nimmt den in der Warteschlange stehenden Job auf. Sie ruft die notwendigen Informationen aus der Datenbank über das mit dem Job verbundene Playbook, Inventar und die Anmeldeinformationen ab.
• Mit dem abgerufenen Ansible-Playbook aus dem zugehörigen Projekt führt die Aufgaben-Engine das Playbook gegen die angegebenen Inventar-Knoten mit den bereitgestellten Anmeldeinformationen aus.
• Während das Playbook ausgeführt wird, werden die Ausführungsprotokolle (Logs, Fakten usw.) erfasst und in der Datenbank gespeichert.

5. Jobergebnisse:

• Sobald das Playbook die Ausführung abgeschlossen hat, werden die Ergebnisse (Erfolg, Misserfolg, Protokolle) in der Datenbank gespeichert.
• Benutzer können die Ergebnisse dann über die Weboberfläche einsehen oder sie über die REST API abfragen.
• Basierend auf den Ergebnissen der Jobs 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.

6. Integration mit externen Systemen:

• Inventare können dynamisch aus externen Systemen bezogen werden, sodass AWX/Tower Hosts aus Quellen wie AWS, Azure, VMware und mehr abrufen kann.
• Projekte (Playbooks) können aus Versionskontrollsystemen abgerufen werden, um sicherzustellen, dass während der Jobausführung aktuelle Playbooks verwendet werden.
• Planer und Rückrufe können verwendet werden, um mit anderen Systemen oder Tools zu integrieren, sodass AWX/Tower auf externe Auslöser reagiert oder Jobs zu festgelegten Zeiten ausführt.

AWX-Laborerstellung für Tests

Den Dokumenten folgend ist es möglich, docker-compose zu verwenden, um AWX auszuführen:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Unterstützte Rollen

Die privilegierteste Rolle wird als Systemadministrator bezeichnet. Jeder mit dieser Rolle kann alles ändern.

Für eine White-Box-Sicherheits-Überprüfung benötigen Sie die Systemauditorrolle, die es ermöglicht, alle Systemdaten anzuzeigen, aber keine Änderungen vorzunehmen. Eine andere Option wäre, die Organisationsauditorrolle zu erhalten, aber es wäre besser, die andere zu bekommen.

Enumeration & Attack-Path Mapping mit AnsibleHound

AnsibleHound ist ein Open-Source BloodHound OpenGraph Sammler, der in Go geschrieben ist und ein read-only Ansible Tower/AWX/Automation Controller API-Token in ein vollständiges Berechtigungsdiagramm umwandelt, das bereit ist, innerhalb von BloodHound (oder BloodHound Enterprise) analysiert zu werden.

Warum ist das nützlich?

1. Die Tower/AWX REST API ist äußerst umfangreich und gibt jedes Objekt und jede RBAC-Beziehung preis, die Ihre Instanz kennt.
2. Selbst mit dem niedrigsten Berechtigungs-Token (Lesen) ist es möglich, alle zugänglichen Ressourcen (Organisationen, Inventare, Hosts, Berechtigungen, Projekte, Jobvorlagen, Benutzer, Teams…) rekursiv aufzulisten.
3. Wenn die Rohdaten in das BloodHound-Schema umgewandelt werden, erhalten Sie die gleichen Angriffsweg-Visualisierungsfähigkeiten, die in Active Directory-Bewertungen so beliebt sind – aber jetzt auf Ihre CI/CD-Umgebung gerichtet.

Sicherheitsteams (und Angreifer!) können daher:

• Schnell verstehen, wer Administrator von was werden kann.
• Berechtigungen oder Hosts identifizieren, die von einem unprivilegierten Konto erreichbar sind.
• Mehrere „Lesen ➜ Verwenden ➜ Ausführen ➜ Admin“-Kanten verknüpfen, um die vollständige Kontrolle über die Tower-Instanz oder die zugrunde liegende Infrastruktur zu erlangen.

Voraussetzungen

• Ansible Tower / AWX / Automation Controller über HTTPS erreichbar.
• Ein Benutzer-API-Token, das nur auf Lesen beschränkt ist (erstellt aus Benutzerdetails → Tokens → Token erstellen → Umfang = Lesen).
• Go ≥ 1.20, um den Sammler zu kompilieren (oder verwenden Sie die vorgefertigten Binärdateien).

Erstellen & Ausführen

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

Internally führt AnsibleHound seitengestützte GET-Anfragen gegen (mindestens) die folgenden Endpunkte durch und folgt automatisch den related-Links, die in jedem JSON-Objekt zurückgegeben werden:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Alle gesammelten Seiten werden in einer einzelnen JSON-Datei auf der Festplatte zusammengeführt (Standard: ansiblehound-output.json).

BloodHound Transformation

Die Rohdaten von Tower werden dann in BloodHound OpenGraph umgewandelt unter Verwendung von benutzerdefinierten Knoten, die mit AT (Ansible Tower) vorangestellt sind:

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

Und Kanten, die Beziehungen / Berechtigungen modellieren:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

Das Ergebnis kann direkt in BloodHound importiert werden:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

Optional können Sie benutzerdefinierte Symbole hochladen, damit die neuen Knotentypen visuell unterscheidbar sind:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Defensive & Offensive Considerations

• Ein Read-Token wird normalerweise als harmlos angesehen, aber es leakt dennoch die vollständige Topologie und alle Anmeldeinformationen-Metadaten. Behandle es als sensibel!
• Erzwinge geringste Privilegien und rotiere / widerrufe ungenutzte Tokens.
• Überwache die API auf übermäßige Enumeration (mehrere aufeinanderfolgende GET-Anfragen, hohe Paginierungsaktivität).
• Aus der Perspektive eines Angreifers ist dies eine perfekte initial foothold → privilege escalation-Technik innerhalb der CI/CD-Pipeline.

References

• AnsibleHound – BloodHound Collector for Ansible Tower/AWX
• BloodHound OSS