Ansible Tower / AWX / Automation controller Security

Zacznij od zera i stań się ekspertem od hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!

• Zdobądź oficjalne gadżety PEASS & HackTricks

• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź mnie na Twitterze 🐦 @hacktricks_live.

• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

Ansible Tower lub jego wersja open source AWX jest również znany jako interfejs użytkownika Ansible, panel i interfejs REST. Dzięki kontroli dostępu opartej na rolach, harmonogramowaniu zadań i graficznemu zarządzaniu inwentarzem, można zarządzać infrastrukturą Ansible za pomocą nowoczesnego interfejsu użytkownika. Interfejs REST i interfejs wiersza poleceń Tower umożliwiają łatwe zintegrowanie go z obecnymi narzędziami i procesami.

Kontroler automatyzacji to nowsza wersja Ansible Tower z większymi możliwościami.

Różnice

Zgodnie z tym, główne różnice między Ansible Tower a AWX to otrzymywane wsparcie, a Ansible Tower ma dodatkowe funkcje, takie jak kontrola dostępu oparta na rolach, obsługa niestandardowych interfejsów API i zdefiniowane przez użytkownika przepływy pracy.

Stos technologiczny

• Interfejs sieciowy: Jest to interfejs graficzny, w którym użytkownicy mogą zarządzać inwentarzami, poświadczeniami, szablonami i zadaniami. Został zaprojektowany tak, aby był intuicyjny i zapewniał wizualizacje pomagające zrozumieć stan i wyniki zadań automatyzacji.

• Interfejs REST: Wszystko, co można zrobić w interfejsie sieciowym, można również zrobić za pomocą interfejsu REST. Oznacza to, że można zintegrować AWX/Tower z innymi systemami lub skryptować działania, które zazwyczaj wykonywałbyś w interfejsie.

• Baza danych: AWX/Tower używa bazy danych (zwykle PostgreSQL) do przechowywania konfiguracji, wyników zadań i innych niezbędnych danych operacyjnych.

• RabbitMQ: To system komunikacji używany przez AWX/Tower do komunikacji między różnymi komponentami, zwłaszcza między usługą sieciową a wykonawcami zadań.

• Redis: Redis służy jako pamięć podręczna i backend dla kolejki zadań.

Składniki logiczne

• Inwentarze: Inwentarz to zbiór hostów (lub węzłów), na których mogą być uruchamiane zadania (playbooki Ansible). AWX/Tower pozwala zdefiniować i grupować inwentarze oraz obsługuje inwentarze dynamiczne, które mogą pobierać listy hostów z innych systemów takich jak AWS, Azure, itp.

• Projekty: Projekt to w zasadzie zbiór playbooków Ansible pobranych z systemu kontroli wersji (np. Git) w celu pobrania najnowszych playbooków w razie potrzeby.

• Szablony: Szablony zadań definiują sposób uruchomienia określonego playbooka, określając inwentarz, poświadczenia i inne parametry dla zadania.

• Poświadczenia: AWX/Tower zapewnia bezpieczny sposób zarządzania i przechowywania tajemnic, takich jak klucze SSH, hasła i tokeny API. Te poświadczenia mogą być powiązane z szablonami zadań, aby playbooki miały niezbędny dostęp podczas uruchamiania.

• Silnik zadań: To tutaj dzieje się magia. Silnik zadań jest oparty na Ansible i odpowiada za uruchamianie playbooków. Zadania są wysyłane do silnika zadań, który następnie uruchamia playbooki Ansible przeciwko określonym węzłom inwentarza, korzystając z określonych poświadczeń.

• Harmonogramy i wywołania zwrotne: Są to zaawansowane funkcje w AWX/Tower, które pozwalają harmonogramować zadania do uruchomienia o określonych godzinach lub wywoływane przez zewnętrzne zdarzenia.

• Powiadomienia: AWX/Tower może wysyłać powiadomienia na podstawie sukcesu lub niepowodzenia zadań. Obsługuje różne sposoby powiadamiania, takie jak e-maile, wiadomości Slack, webhooks, itp.

• Playbooki Ansible: Playbooki Ansible to narzędzia konfiguracji, wdrożenia i orkiestracji. Opisują one pożądany stan systemów w zautomatyzowany, powtarzalny sposób. Napisane w formacie YAML, playbooki używają deklaratywnego języka automatyzacji Ansible do opisywania konfiguracji, zadań i kroków, które należy wykonać.

Przepływ wykonania zadania

1. Interakcja użytkownika: Użytkownik może współdziałać z AWX/Tower poprzez interfejs sieciowy lub interfejs REST. Zapewniają one dostęp do wszystkich funkcji oferowanych przez AWX/Tower.

2. Inicjowanie zadania:

• Użytkownik, za pośrednictwem interfejsu sieciowego lub interfejsu API, inicjuje zadanie na podstawie Szablonu zadania.

• Szablon zadania zawiera odniesienia do Inwentarza, Projektu (zawierającego playbook) i Poświadczeń.

• Po zainicjowaniu zadania, żądanie jest wysyłane do backendu AWX/Tower, aby umieścić zadanie w kolejce do wykonania.

3. Kolejkowanie zadań:

• RabbitMQ obsługuje komunikację między komponentem sieciowym a wykonawcami zadań. Po zainicjowaniu zadania, wiadomość jest wysyłana do silnika zadań za pomocą RabbitMQ.

• Redis działa jako backend dla kolejki zadań, zarządzając zadaniami w kolejce oczekującymi na wykonanie.

4. Wykonanie zadania:

• Silnik zadań podnosi zadanie z kolejki. Pobiera niezbędne informacje z Bazy danych dotyczące powiązanego playbooka, inwentarza i poświadczeń zadania.

• Korzystając z pobranego playbooka Ansible z powiązanego Projektu, Silnik zadań uruchamia playbook przeciwko określonym węzłom Inwentarza przy użyciu podanych Poświadczeń.

• Podczas uruchamiania playbooka, jego wyniki wykonania (logi, fakty, itp.) są przechwytywane i przechowywane w Bazie danych.

5. Wyniki zadania:

• Po zakończeniu uruchamiania playbooka, wyniki (sukces, niepowodzenie, logi) są zapisywane w Bazie danych.

• Użytkownicy mogą następnie przeglądać wyniki za pomocą interfejsu sieciowego lub zapytywać o nie za pomocą interfejsu REST.

• Na podstawie wyników zadania, Powiadomienia mogą być wysyłane, informując użytkowników lub zewnętrzne systemy o statusie zadania. Powiadomienia mogą być e-mailami, wiadomościami Slack, webhookami, itp.

6. Integracja z zewnętrznymi systemami:

• Inwentarze mogą być dynamicznie pobierane z zewnętrznych systemów, umożliwiając AWX/Tower pobieranie hostów z takich źródeł jak AWS, Azure, VMware i inne.

• Projekty (playbooki) mogą być pobierane z systemów kontroli wersji, zapewniając użycie aktualnych playbooków podczas wykonywania zadań.

• Harmonogramy i wywołania zwrotne mogą być używane do integracji z innymi systemami lub narzędziami, umożliwiając AWX/Tower reagowanie na zewnętrzne wyzwalacze lub uruchamianie zadań o określonych godzinach.

Utworzenie laboratorium AWX do testów

Zgodnie z dokumentacją można użyć docker-compose do uruchomienia AWX:

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

Obsługiwane role

Najbardziej uprzywilejowaną rolą jest Administrator systemu. Osoba posiadająca tę rolę może modyfikować wszystko.

Z przeglądu białej skrzynki wynika, że potrzebna byłaby rola Audytora systemu, która pozwala wyświetlać wszystkie dane systemowe, ale nie może dokonywać żadnych zmian. Inna opcja to uzyskanie roli Audytora organizacji, ale lepiej byłoby uzyskać tę pierwszą.

Rozwiń, aby uzyskać szczegółowy opis dostępnych ról

1. Administrator systemu:

• Jest to rola superużytkownika z uprawnieniami do dostępu i modyfikowania dowolnego zasobu w systemie.

• Mogą zarządzać wszystkimi organizacjami, zespołami, projektami, inwentarzami, szablonami zadań, itp.

2. Auditor systemu:

• Użytkownicy z tą rolą mogą przeglądać wszystkie dane systemowe, ale nie mogą dokonywać żadnych zmian.

• Rola ta jest przeznaczona do zgodności i nadzoru.

3. Role organizacji:

• Admin: Pełna kontrola nad zasobami organizacji.

• Auditor: Dostęp tylko do odczytu zasobów organizacji.

• Członek: Podstawowe członkostwo w organizacji bez konkretnych uprawnień.

• Wykonaj: Może uruchamiać szablony zadań w organizacji.

• Odczyt: Może przeglądać zasoby organizacji.

4. Role projektu:

• Admin: Może zarządzać i modyfikować projekt.

• Użyj: Może użyć projektu w szablonie zadania.

• Aktualizuj: Może aktualizować projekt za pomocą SCM (kontroli źródła).

5. Role inwentarza:

• Admin: Może zarządzać i modyfikować inwentarz.

• Ad hoc: Może uruchamiać polecenia ad hoc na inwentarzu.

• Aktualizuj: Może aktualizować źródło inwentarza.

• Użyj: Może użyć inwentarza w szablonie zadania.

• Odczyt: Dostęp tylko do odczytu.

6. Role szablonu zadania:

• Admin: Może zarządzać i modyfikować szablon zadania.

• Wykonaj: Może uruchomić zadanie.

• Odczyt: Dostęp tylko do odczytu.

7. Role poświadczenia:

• Admin: Może zarządzać i modyfikować poświadczenia.

• Użyj: Może użyć poświadczeń w szablonach zadań lub innych odpowiednich zasobach.

• Odczyt: Dostęp tylko do odczytu.

8. Role zespołu:

• Członek: Część zespołu, ale bez konkretnych uprawnień.

• Admin: Może zarządzać członkami zespołu i powiązanymi zasobami.

9. Role przepływu pracy:

• Admin: Może zarządzać i modyfikować przepływ pracy.

• Wykonaj: Może uruchomić przepływ pracy.

• Odczyt: Dostęp tylko do odczytu.