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 ou sa version open source 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.

Automation Controller est une version plus récente d'Ansible Tower avec plus de capacités.

Differences

Selon ceci, les principales différences entre Ansible Tower et AWX sont le support reçu et Ansible Tower a des fonctionnalités supplémentaires telles que le contrôle d'accès basé sur les rôles, le support pour les API personnalisées et les flux de travail définis par l'utilisateur.

Tech Stack

• Web Interface : 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.

• REST API : 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.

• Database : 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.

Logical Components

• Inventories : Un inventaire est une collection d'hôtes (ou 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.

• Projects : 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.

• Templates : 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.

• Credentials : 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.

• Task Engine : 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.

• Schedulers and Callbacks : 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.

• Ansible Playbooks : 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.

Job Execution Flow

1. User Interaction : Un utilisateur peut interagir avec AWX/Tower soit via l'interface Web soit via l'API REST. Celles-ci fournissent un accès frontal à toutes les fonctionnalités offertes par AWX/Tower.

2. Job Initiation :

• 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. Job Queuing :

• 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 en attente d'exécution.

4. Job Execution :

• Le moteur de tâches prend la tâche 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 d'inventaire spécifiés 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. Job Results :

• 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. External Systems Integration :

• Les inventaires peuvent être récupérés dynamiquement à partir de systèmes externes, permettant à AWX/Tower de tirer des hôtes de sources comme 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.

AWX lab creation for testing

Following the docs il est possible d'utiliser docker-compose pour exécuter 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

Rôles pris en charge

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

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.

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

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.

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.