# Ansible Tower / AWX / Automatiseringsbeheerder Sekuriteit

{{#include ../banners/hacktricks-training.md}}

## Basiese Inligting

**Ansible Tower** of sy oopbron weergawe [**AWX**](https://github.com/ansible/awx) is ook bekend as **Ansible se gebruikerskoppelvlak, dashboard, en REST API**. Met **rolgebaseerde toegangbeheer**, werkskedulering, en grafiese inventarisbestuur, kan jy jou Ansible-infrastruktuur vanaf 'n moderne UI bestuur. Tower se REST API en opdraglyn koppelvlak maak dit eenvoudig om dit in huidige gereedskap en werksvloei te integreer.

**Automatiseringsbeheerder is 'n nuwer** weergawe van Ansible Tower met meer vermoëns.

### Verskille

Volgens [**hierdie**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), is die hoofverskille tussen Ansible Tower en AWX die ontvangde ondersteuning en die Ansible Tower het addisionele funksies soos rolgebaseerde toegangbeheer, ondersteuning vir pasgemaakte API's, en gebruikersgedefinieerde werksvloei.

### Tegnologiesteke

- **Web Koppelvlak**: Dit is die grafiese koppelvlak waar gebruikers inventarisse, akrediteer, sjablone, en werksgeleenthede kan bestuur. Dit is ontwerp om intuïtief te wees en bied visualisasies om te help met die begrip van die toestand en resultate van jou automatiseringswerk.
- **REST API**: Alles wat jy in die web koppelvlak kan doen, kan jy ook via die REST API doen. Dit beteken jy kan AWX/Tower met ander stelsels integreer of aksies skryf wat jy tipies in die koppelvlak sou uitvoer.
- **Databasis**: AWX/Tower gebruik 'n databasis (tipies PostgreSQL) om sy konfigurasie, werksresultate, en ander nodige operasionele data te stoor.
- **RabbitMQ**: Dit is die boodskapstelsel wat deur AWX/Tower gebruik word om tussen die verskillende komponente te kommunikeer, veral tussen die webdiens en die taaklopers.
- **Redis**: Redis dien as 'n kas en 'n agtergrond vir die taaklyn.

### Logiese Komponente

- **Inventarisse**: 'n Inventaris is 'n **versameling van gasheers (of nodes)** teenoor wie se **werksgeleenthede** (Ansible speelboeke) kan **loop**. AWX/Tower laat jou toe om jou inventarisse te definieer en te groepeer en ondersteun ook dinamiese inventarisse wat **gasheerlis te kan haal van ander stelsels** soos AWS, Azure, ens.
- **Projekte**: 'n Projek is in wese 'n **versameling van Ansible speelboeke** wat afkomstig is van 'n **weergawebeheerstelsel** (soos Git) om die nuutste speelboeke te trek wanneer nodig.
- **Sjablone**: Werk sjablone definieer **hoe 'n spesifieke speelboek uitgevoer sal word**, wat die **inventaris**, **akrediteer**, en ander **parameters** vir die werk spesifiseer.
- **Akrediteer**: AWX/Tower bied 'n veilige manier om **geheime te bestuur en te stoor, soos SSH sleutels, wagwoorde, en API tokens**. Hierdie akrediteer kan met werksjablone geassosieer word sodat speelboeke die nodige toegang het wanneer hulle loop.
- **Taak Enjin**: Dit is waar die magie gebeur. Die taak enjin is gebou op Ansible en is verantwoordelik vir **die speelboeke uit te voer**. Werksgeleenthede word na die taak enjin gestuur, wat dan die Ansible speelboeke teen die aangewese inventaris met die gespesifiseerde akrediteer uitvoer.
- **Skeerders en Terugroepe**: Dit is gevorderde funksies in AWX/Tower wat toelaat dat **werksgeleenthede geskeduleer kan word** om op spesifieke tye te loop of geaktiveer te word deur eksterne gebeurtenisse.
- **Kennisgewings**: AWX/Tower kan kennisgewings stuur gebaseer op die sukses of mislukking van werksgeleenthede. Dit ondersteun verskeie middele van kennisgewings soos e-pos, Slack boodskappe, webhooks, ens.
- **Ansible Speelboeke**: Ansible speelboeke is konfigurasie, ontplooiing, en orkestrasie gereedskap. Hulle beskryf die gewenste toestand van stelsels op 'n geoutomatiseerde, herhaalbare manier. Geskryf in YAML, gebruik speelboeke Ansible se verklarende outomatiseringstaal om konfigurasies, take, en stappe wat uitgevoer moet word te beskryf.

### Werk Uitvoering Stroom

1. **Gebruiker Interaksie**: 'n gebruiker kan met AWX/Tower interaksie hê of deur die **Web Koppelvlak** of die **REST API**. Hierdie bied front-end toegang tot al die funksies wat deur AWX/Tower aangebied word.
2. **Werk Inisiasie**:
- Die gebruiker, via die Web Koppelvlak of API, inisieer 'n werk gebaseer op 'n **Werk Sjabloon**.
- Die Werk Sjabloon sluit verwysings in na die **Inventaris**, **Projekt** (wat die speelboek bevat), en **Akrediteer**.
- By werk inisiasie, word 'n versoek na die AWX/Tower agtergrond gestuur om die werk vir uitvoering te queue.
3. **Werk Queuing**:
- **RabbitMQ** hanteer die boodskappe tussen die webkomponent en die taaklopers. Sodra 'n werk geinisieer is, word 'n boodskap na die taak enjin gestuur met behulp van RabbitMQ.
- **Redis** dien as die agtergrond vir die taaklyn, wat gequeue werksgeleenthede wat wag vir uitvoering bestuur.
4. **Werk Uitvoering**:
- Die **Taak Enjin** neem die gequeue werk op. Dit haal die nodige inligting van die **Databasis** oor die werk se geassosieerde speelboek, inventaris, en akrediteer.
- Met die onttrokken Ansible speelboek van die geassosieerde **Projekt**, voer die Taak Enjin die speelboek teen die gespesifiseerde **Inventaris** nodes uit met die verskafde **Akrediteer**.
- Soos die speelboek loop, word sy uitvoeringsuitset (logs, feite, ens.) vasgevang en in die **Databasis** gestoor.
5. **Werk Resultate**:
- Sodra die speelboek klaar is met loop, word die resultate (sukses, mislukking, logs) in die **Databasis** gestoor.
- Gebruikers kan dan die resultate deur die Web Koppelvlak sien of dit via die REST API opvra.
- Gebaseer op werksuitkomste, kan **Kennisgewings** gestuur word om gebruikers of eksterne stelsels oor die werk se status in te lig. Kennisgewings kan e-posse, Slack boodskappe, webhooks, ens. wees.
6. **Eksterne Stelsels Integrasie**:
- **Inventarisse** kan dinamies van eksterne stelsels verkry word, wat AWX/Tower toelaat om gasheers van bronne soos AWS, Azure, VMware, en meer in te trek.
- **Projekte** (speelboeke) kan van weergawebeheerstelsels verkry word, wat die gebruik van op-datum speelboeke tydens werk uitvoering verseker.
- **Skeerders en Terugroepe** kan gebruik word om met ander stelsels of gereedskap te integreer, wat AWX/Tower laat reageer op eksterne triggers of werksgeleenthede op voorafbepaalde tye te laat loop.

### AWX laboratoriumskepping vir toetsing

[**Volg die dokumentasie**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) is dit moontlik om docker-compose te gebruik om AWX te loop:
```bash
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

### Ondersteunde rolle

Die mees bevoorregte rol word **Sisteem Administrateur** genoem. Enigeen met hierdie rol kan **enige iets** **wysig**.

Vanuit 'n **wit boks sekuriteit** hersiening, sal jy die **Sisteem Ouditeur rol** benodig, wat toelaat om **alle sisteemdata** te **bekyk** maar geen veranderinge kan aanbring nie. 'n Ander opsie sou wees om die **Organisasie Ouditeur rol** te verkry, maar dit sou beter wees om die ander een te kry.

<details>

<summary>Breek dit uit om 'n gedetailleerde beskrywing van beskikbare rolle te kry</summary>

1. **Sisteem Administrateur**:
- Dit is die supergebruiker rol met regte om toegang te verkry en enige hulpbron in die sisteem te wysig.
- Hulle kan alle organisasies, spanne, projekte, inventarisse, werksjablone, ens. bestuur.
2. **Sisteem Ouditeur**:
- Gebruikers met hierdie rol kan alle sisteemdata bekijk maar kan geen veranderinge aanbring nie.
- Hierdie rol is ontwerp vir nakoming en toesig.
3. **Organisasie Rolle**:
- **Admin**: Volle beheer oor die organisasie se hulpbronne.
- **Ouditeur**: Slegs lees toegang tot die organisasie se hulpbronne.
- **Lid**: Basiese lidmaatskap in 'n organisasie sonder enige spesifieke regte.
- **Voer Uit**: Kan werksjablone binne die organisasie uitvoer.
- **Lees**: Kan die organisasie se hulpbronne bekijk.
4. **Projek Rolle**:
- **Admin**: Kan die projek bestuur en wysig.
- **Gebruik**: Kan die projek in 'n werksjabloon gebruik.
- **Opdateer**: Kan die projek opdateer met SCM (bronbeheer).
5. **Inventaris Rolle**:
- **Admin**: Kan die inventaris bestuur en wysig.
- **Ad Hoc**: Kan ad hoc opdragte op die inventaris uitvoer.
- **Opdateer**: Kan die inventarisbron opdateer.
- **Gebruik**: Kan die inventaris in 'n werksjabloon gebruik.
- **Lees**: Slegs lees toegang.
6. **Werksjabloon Rolle**:
- **Admin**: Kan die werksjabloon bestuur en wysig.
- **Voer Uit**: Kan die werk uitvoer.
- **Lees**: Slegs lees toegang.
7. **Geloofsbriewe Rolle**:
- **Admin**: Kan die geloofsbriewe bestuur en wysig.
- **Gebruik**: Kan die geloofsbriewe in werksjablone of ander relevante hulpbronne gebruik.
- **Lees**: Slegs lees toegang.
8. **Span Rolle**:
- **Lid**: Deel van die span maar sonder enige spesifieke regte.
- **Admin**: Kan die span se lede en geassosieerde hulpbronne bestuur.
9. **Werkvloei Rolle**:
- **Admin**: Kan die werkvloei bestuur en wysig.
- **Voer Uit**: Kan die werkvloei uitvoer.
- **Lees**: Slegs lees toegang.

</details>

## Enumerasie & Aanvalspad Kaartlegging met AnsibleHound

`AnsibleHound` is 'n oopbron BloodHound *OpenGraph* versameling geskryf in Go wat 'n **slegs lees** Ansible Tower/AWX/Automatiseringsbeheer API-token in 'n volledige toestemmingsgrafiek omskakel wat gereed is om binne BloodHound (of BloodHound Enterprise) geanaliseer te word.

### Waarom is dit nuttig?
1. Die Tower/AWX REST API is uiters ryk en stel **elke objek en RBAC verhouding** wat jou instansie ken, bloot.
2. Selfs met die laagste voorreg (**Lees**) token is dit moontlik om alle toeganklike hulpbronne (organisasies, inventarisse, gasheer, geloofsbriewe, projekte, werksjablone, gebruikers, spanne…) rekursief te enumerate.
3. Wanneer die rou data na die BloodHound skema omgeskakel word, verkry jy dieselfde *aanvalspad* visualisering vermoëns wat so gewild is in Aktiewe Gids assessments – maar nou gerig op jou CI/CD eiendom.

Sekuriteitspanne (en aanvallers!) kan dus:
* Vinnig verstaan **wie admin van wat kan word**.
* Identifiseer **geloofsbriewe of gasheer wat bereik kan word** vanaf 'n nie-bevoorregte rekening.
* Meerdere “Lees ➜ Gebruik ➜ Voer Uit ➜ Admin” kante ketting om volle beheer oor die Tower instansie of die onderliggende infrastruktuur te verkry.

### Voorvereistes
* Ansible Tower / AWX / Automatiseringsbeheer bereikbaar oor HTTPS.
* 'n gebruiker API-token wat slegs op **Lees** geskaal is (gecreëer vanaf *Gebruiker Besonderhede → Tokens → Token Skep → skaal = Lees*).
* Go ≥ 1.20 om die versameling te kompileer (of gebruik die voorafgeboude binêre). 

### Bou & Loop
```bash
# 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"
```
Intern intern AnsibleHound voer *gepagineerde* `GET` versoeke uit teen (ten minste) die volgende eindpunte en volg outomaties die `verwante` skakels wat in elke JSON-objek teruggestuur word:
```
/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 versamelde bladsye word in 'n enkele JSON-lêer op skyf saamgevoeg (verstek: `ansiblehound-output.json`).

### BloodHound Transformasie
Die rou Tower-data word dan **getransformeer na BloodHound OpenGraph** met behulp van pasgemaakte knope wat met `AT` (Ansible Tower) voorafgegaan word:
* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`

En rande wat verhoudings / voorregte modelleer:
* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`

Die resultaat kan regstreeks in BloodHound ingevoer word:
```bash
neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json
```
U kan **pasgemaakte ikone** opslaan sodat die nuwe knooppunt tipes visueel onderskeibaar is:
```bash
python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
```
### Verdedigende & Aanvallende Oorwegings
* 'n *Read* token word normaalweg as onskadelik beskou, maar lek steeds die **volledige topologie en elke geloofsbrief metadata**. Behandel dit as sensitief!
* Handhaaf **minimale bevoegdheid** en draai / herroep ongebruikte tokens.
* Monitor die API vir oormatige enumerasie (meervoudige opeenvolgende `GET` versoeke, hoë paginering aktiwiteit).
* Vanuit 'n aanvaller se perspektief is dit 'n perfekte *beginpunt → bevoegdheid eskalasie* tegniek binne die CI/CD pyplyn.

## Verwysings
* [AnsibleHound – BloodHound Collector for Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)

{{#include ../banners/hacktricks-training.md}}
