Ansible Tower / AWX / Automation controller Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Ansible Tower lub jego wersja open source AWX jest znany jako interfejs użytkownika Ansible, pulpit nawigacyjny i REST API. Dzięki kontroli dostępu opartej na rolach, harmonogramowaniu zadań i graficznemu zarządzaniu inwentarzem, możesz zarządzać swoją infrastrukturą Ansible z nowoczesnego interfejsu. REST API Towera i interfejs wiersza poleceń ułatwiają integrację z obecnymi narzędziami i przepływami pracy.

Automation Controller to nowsza wersja Ansible Tower z większymi możliwościami.

Differences

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, wsparcie dla niestandardowych API i zdefiniowane przez użytkownika przepływy pracy.

Tech Stack

• Web Interface: To graficzny interfejs, w którym użytkownicy mogą zarządzać inwentarzami, poświadczeniami, szablonami i zadaniami. Został zaprojektowany tak, aby był intuicyjny i zapewniał wizualizacje, które pomagają w zrozumieniu stanu i wyników twoich zadań automatyzacji.

• REST API: Wszystko, co możesz zrobić w interfejsie webowym, możesz również zrobić za pomocą REST API. Oznacza to, że możesz zintegrować AWX/Tower z innymi systemami lub skryptować działania, które zazwyczaj wykonujesz w interfejsie.

• Database: AWX/Tower używa bazy danych (zwykle PostgreSQL) do przechowywania swojej 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, szczególnie między usługą webową a wykonawcami zadań.

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

Logical Components

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

• Projects: Projekt to zasadniczo zbiór playbooków Ansible pozyskiwanych z systemu kontroli wersji (takiego jak Git), aby pobierać najnowsze playbooki w razie potrzeby.

• Templates: Szablony zadań definiują jak dany playbook będzie uruchamiany, określając inwentarz, poświadczenia i inne parametry dla zadania.

• Credentials: AWX/Tower zapewnia bezpieczny sposób zarządzania i przechowywania sekretów, 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.

• Task Engine: To tutaj dzieje się magia. Silnik zadań oparty jest na Ansible i odpowiada za uruchamianie playbooków. Zadania są przekazywane do silnika zadań, który następnie uruchamia playbooki Ansible na wyznaczonym inwentarzu, używając określonych poświadczeń.

• Schedulers and Callbacks: To zaawansowane funkcje w AWX/Tower, które pozwalają na harmonogramowanie zadań do uruchamiania w określonych czasach lub wyzwalane przez zdarzenia zewnętrzne.

• Notifications: AWX/Tower może wysyłać powiadomienia w zależności od sukcesu lub niepowodzenia zadań. Obsługuje różne formy powiadomień, takie jak e-maile, wiadomości Slack, webhooki itp.

• Ansible Playbooks: Playbooki Ansible to narzędzia do konfiguracji, wdrażania i orkiestracji. Opisują pożądany stan systemów w sposób zautomatyzowany i powtarzalny. Napisane w YAML, playbooki używają deklaratywnego języka automatyzacji Ansible do opisywania konfiguracji, zadań i kroków, które muszą być wykonane.

Job Execution Flow

1. User Interaction: Użytkownik może interagować z AWX/Tower za pośrednictwem Web Interface lub REST API. Te zapewniają dostęp front-end do wszystkich funkcji oferowanych przez AWX/Tower.

2. Job Initiation:

• Użytkownik, za pośrednictwem interfejsu webowego lub API, inicjuje zadanie na podstawie Job Template.

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

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

1. Job Queuing:

• RabbitMQ obsługuje komunikację między komponentem webowym a wykonawcami zadań. Gdy zadanie jest inicjowane, wiadomość jest wysyłana do silnika zadań za pomocą RabbitMQ.

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

1. Job Execution:

• Task Engine odbiera zadanie z kolejki. Pobiera niezbędne informacje z Database o powiązanym playbooku, inwentarzu i poświadczeniach.

• Używając pobranego playbooka Ansible z powiązanego Projektu, silnik zadań uruchamia playbook na wyznaczonych węzłach Inventory używając podanych Credentials.

• W miarę uruchamiania playbooka, jego wyniki wykonania (logi, fakty itp.) są rejestrowane i przechowywane w Database.

1. Job Results:

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

• Użytkownicy mogą następnie przeglądać wyniki za pośrednictwem interfejsu webowego lub zapytać je za pomocą REST API.

• W zależności od wyników zadań, Notifications mogą być wysyłane, aby informować użytkowników lub zewnętrzne systemy o statusie zadania. Powiadomienia mogą być e-mailami, wiadomościami Slack, webhookami itp.

1. External Systems Integration:

• Inventories mogą być dynamicznie pozyskiwane z systemów zewnętrznych, co pozwala AWX/Tower na pobieranie hostów z takich źródeł jak AWS, Azure, VMware i inne.

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

• Schedulers and Callbacks mogą być używane do integracji z innymi systemami lub narzędziami, co sprawia, że AWX/Tower reaguje na zewnętrzne wyzwalacze lub uruchamia zadania w ustalonych czasach.

AWX lab creation for testing

Following the docs it's possible to use docker-compose to run 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. Każdy, kto ma tę rolę, może modyfikować wszystko.

Z perspektywy przeglądu bezpieczeństwa białej skrzynki, potrzebujesz roli Audytora Systemu, która pozwala na przeglądanie wszystkich danych systemowych, ale nie może wprowadzać żadnych zmian. Inną opcją byłoby uzyskanie roli Audytora Organizacji, ale lepiej byłoby uzyskać tę drugą.

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

1. Administrator Systemu:

• To rola superużytkownika z uprawnieniami do dostępu i modyfikacji każdego zasobu w systemie.

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

1. Audytor Systemu:

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

• Ta rola jest zaprojektowana do celów zgodności i nadzoru.

1. Role Organizacji:

• Admin: Pełna kontrola nad zasobami organizacji.

• Audytor: Tylko dostęp do przeglądania zasobów organizacji.

• Członek: Podstawowe członkostwo w organizacji bez żadnych specyficznych uprawnień.

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

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

1. Role Projektów:

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

• Użyj: Może używać projektu w szablonie zadań.

• Aktualizuj: Może aktualizować projekt za pomocą SCM (kontrola wersji).

1. 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żywać inwentarza w szablonie zadań.

• Przeczytaj: Tylko dostęp do przeglądania.

1. Role Szablonów Zadań:

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

• Wykonaj: Może uruchomić zadanie.

• Przeczytaj: Tylko dostęp do przeglądania.

1. Role Poświadczeń:

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

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

• Przeczytaj: Tylko dostęp do przeglądania.

1. Role Zespołów:

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

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

1. Role Przepływu Pracy:

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

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

• Przeczytaj: Tylko dostęp do przeglądania.

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

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

• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.