# Ansible Tower / AWX / Sécurité du contrôleur d'automatisation

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

## Informations de base

**Ansible Tower** ou sa version open source [**AWX**](https://github.com/ansible/awx) est également connu comme **l'interface utilisateur, le tableau de bord et l'API REST d'Ansible**. Avec **le contrôle d'accès basé sur les rôles**, la planification des tâches et la gestion graphique des inventaires, vous pouvez gérer votre infrastructure Ansible depuis une interface moderne. L'API REST de Tower et l'interface en ligne de commande facilitent son intégration dans les outils et flux de travail actuels.

**Le contrôleur d'automatisation est une version plus récente** d'Ansible Tower avec plus de capacités.

### Différences

Selon [**ceci**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), les principales différences entre Ansible Tower et AWX sont le support reçu et Ansible Tower dispose de fonctionnalités supplémentaires telles que le contrôle d'accès basé sur les rôles, le support des API personnalisées et des flux de travail définis par l'utilisateur.

### Stack technologique

- **Interface Web** : C'est l'interface graphique où les utilisateurs peuvent gérer les inventaires, les identifiants, les modèles et les tâches. Elle est conçue pour être intuitive et fournit des visualisations pour aider à comprendre l'état et les résultats de vos tâches d'automatisation.
- **API REST** : Tout ce que vous pouvez faire dans l'interface web, vous pouvez également le faire via l'API REST. Cela signifie que vous pouvez intégrer AWX/Tower avec d'autres systèmes ou script des actions que vous effectueriez normalement dans l'interface.
- **Base de données** : AWX/Tower utilise une base de données (généralement PostgreSQL) pour stocker sa configuration, les résultats des tâches et d'autres données opérationnelles nécessaires.
- **RabbitMQ** : C'est le système de messagerie utilisé par AWX/Tower pour communiquer entre les différents composants, en particulier entre le service web et les exécuteurs de tâches.
- **Redis** : Redis sert de cache et de backend pour la file d'attente des tâches.

### Composants logiques

- **Inventaires** : Un inventaire est une **collection d'hôtes (ou de nœuds)** contre lesquels des **tâches** (playbooks Ansible) peuvent être **exécutées**. AWX/Tower vous permet de définir et de regrouper vos inventaires et prend également en charge les inventaires dynamiques qui peuvent **récupérer des listes d'hôtes à partir d'autres systèmes** comme AWS, Azure, etc.
- **Projets** : Un projet est essentiellement une **collection de playbooks Ansible** provenant d'un **système de contrôle de version** (comme Git) pour tirer les derniers playbooks lorsque nécessaire.
- **Modèles** : Les modèles de tâches définissent **comment un playbook particulier sera exécuté**, spécifiant l'**inventaire**, les **identifiants** et d'autres **paramètres** pour la tâche.
- **Identifiants** : AWX/Tower fournit un moyen sécurisé de **gérer et de stocker des secrets, tels que des clés SSH, des mots de passe et des jetons API**. Ces identifiants peuvent être associés à des modèles de tâches afin que les playbooks aient l'accès nécessaire lorsqu'ils s'exécutent.
- **Moteur de tâches** : C'est là que la magie opère. Le moteur de tâches est construit sur Ansible et est responsable de **l'exécution des playbooks**. Les tâches sont envoyées au moteur de tâches, qui exécute ensuite les playbooks Ansible contre l'inventaire désigné en utilisant les identifiants spécifiés.
- **Planificateurs et rappels** : Ce sont des fonctionnalités avancées dans AWX/Tower qui permettent aux **tâches d'être planifiées** pour s'exécuter à des moments spécifiques ou déclenchées par des événements externes.
- **Notifications** : AWX/Tower peut envoyer des notifications en fonction du succès ou de l'échec des tâches. Il prend en charge divers moyens de notifications tels que les e-mails, les messages Slack, les webhooks, etc.
- **Playbooks Ansible** : Les playbooks Ansible sont des outils de configuration, de déploiement et d'orchestration. Ils décrivent l'état souhaité des systèmes de manière automatisée et répétable. Écrits en YAML, les playbooks utilisent le langage d'automatisation déclaratif d'Ansible pour décrire les configurations, les tâches et les étapes qui doivent être exécutées.

### Flux d'exécution des tâches

1. **Interaction utilisateur** : Un utilisateur peut interagir avec AWX/Tower soit via l'**Interface Web** soit via l'**API REST**. Ces interfaces fournissent un accès frontal à toutes les fonctionnalités offertes par AWX/Tower.
2. **Initiation de la tâche** :
   - L'utilisateur, via l'Interface Web ou l'API, initie une tâche basée sur un **Modèle de Tâche**.
   - Le Modèle de Tâche inclut des références à l'**Inventaire**, au **Projet** (contenant le playbook) et aux **Identifiants**.
   - Lors de l'initiation de la tâche, une demande est envoyée au backend d'AWX/Tower pour mettre la tâche en file d'attente pour exécution.
3. **Mise en file d'attente de la tâche** :
   - **RabbitMQ** gère la messagerie entre le composant web et les exécuteurs de tâches. Une fois qu'une tâche est initiée, un message est envoyé au moteur de tâches en utilisant RabbitMQ.
   - **Redis** agit comme le backend pour la file d'attente des tâches, gérant les tâches mises en file d'attente en attente d'exécution.
4. **Exécution de la tâche** :
   - Le **Moteur de Tâches** prend la tâche mise en file d'attente. Il récupère les informations nécessaires à partir de la **Base de données** concernant le playbook associé à la tâche, l'inventaire et les identifiants.
   - En utilisant le playbook Ansible récupéré du **Projet** associé, le Moteur de Tâches exécute le playbook contre les nœuds de l'**Inventaire** spécifié en utilisant les **Identifiants** fournis.
   - Au fur et à mesure que le playbook s'exécute, sa sortie d'exécution (journaux, faits, etc.) est capturée et stockée dans la **Base de données**.
5. **Résultats de la tâche** :
   - Une fois que le playbook a terminé son exécution, les résultats (succès, échec, journaux) sont enregistrés dans la **Base de données**.
   - Les utilisateurs peuvent ensuite consulter les résultats via l'Interface Web ou les interroger via l'API REST.
   - En fonction des résultats des tâches, des **Notifications** peuvent être envoyées pour informer les utilisateurs ou les systèmes externes de l'état de la tâche. Les notifications peuvent être des e-mails, des messages Slack, des webhooks, etc.
6. **Intégration avec des systèmes externes** :
   - Les **Inventaires** peuvent être récupérés dynamiquement à partir de systèmes externes, permettant à AWX/Tower de tirer des hôtes de sources telles que AWS, Azure, VMware, et plus encore.
   - Les **Projets** (playbooks) peuvent être récupérés à partir de systèmes de contrôle de version, garantissant l'utilisation de playbooks à jour lors de l'exécution des tâches.
   - Les **Planificateurs et Rappels** peuvent être utilisés pour s'intégrer à d'autres systèmes ou outils, permettant à AWX/Tower de réagir à des déclencheurs externes ou d'exécuter des tâches à des moments prédéterminés.

### Création de laboratoire AWX pour les tests

[**Suivant la documentation**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md), il est possible d'utiliser docker-compose pour exécuter AWX :
```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

### Rôles pris en charge

Le rôle le plus privilégié s'appelle **Administrateur Système**. Quiconque a ce rôle peut **modifier quoi que ce soit**.

D'un examen de **sécurité en boîte blanche**, vous auriez besoin du **rôle d'Auditeur Système**, qui permet de **voir toutes les données du système** mais ne peut apporter aucune modification. Une autre option serait d'obtenir le **rôle d'Auditeur d'Organisation**, mais il serait préférable d'obtenir l'autre.

<details>

<summary>Développez ceci pour obtenir une description détaillée des rôles disponibles</summary>

1. **Administrateur Système** :
- C'est le rôle de superutilisateur avec des permissions pour accéder et modifier n'importe quelle ressource dans le système.
- Ils peuvent gérer toutes les organisations, équipes, projets, inventaires, modèles de travail, etc.
2. **Auditeur Système** :
- Les utilisateurs avec ce rôle peuvent voir toutes les données du système mais ne peuvent apporter aucune modification.
- Ce rôle est conçu pour la conformité et la supervision.
3. **Rôles d'Organisation** :
- **Admin** : Contrôle total sur les ressources de l'organisation.
- **Auditeur** : Accès en lecture seule aux ressources de l'organisation.
- **Membre** : Adhésion de base à une organisation sans permissions spécifiques.
- **Exécuter** : Peut exécuter des modèles de travail au sein de l'organisation.
- **Lire** : Peut voir les ressources de l'organisation.
4. **Rôles de Projet** :
- **Admin** : Peut gérer et modifier le projet.
- **Utiliser** : Peut utiliser le projet dans un modèle de travail.
- **Mettre à jour** : Peut mettre à jour le projet en utilisant SCM (contrôle de version).
5. **Rôles d'Inventaire** :
- **Admin** : Peut gérer et modifier l'inventaire.
- **Ad Hoc** : Peut exécuter des commandes ad hoc sur l'inventaire.
- **Mettre à jour** : Peut mettre à jour la source de l'inventaire.
- **Utiliser** : Peut utiliser l'inventaire dans un modèle de travail.
- **Lire** : Accès en lecture seule.
6. **Rôles de Modèle de Travail** :
- **Admin** : Peut gérer et modifier le modèle de travail.
- **Exécuter** : Peut exécuter le travail.
- **Lire** : Accès en lecture seule.
7. **Rôles de Credential** :
- **Admin** : Peut gérer et modifier les identifiants.
- **Utiliser** : Peut utiliser les identifiants dans des modèles de travail ou d'autres ressources pertinentes.
- **Lire** : Accès en lecture seule.
8. **Rôles d'Équipe** :
- **Membre** : Partie de l'équipe mais sans permissions spécifiques.
- **Admin** : Peut gérer les membres de l'équipe et les ressources associées.
9. **Rôles de Workflow** :
- **Admin** : Peut gérer et modifier le workflow.
- **Exécuter** : Peut exécuter le workflow.
- **Lire** : Accès en lecture seule.

</details>

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