Ansible Tower / AWX / Automation controller Security

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez La famille PEASS, notre collection exclusive de NFTs

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦 @hacktricks_live.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.

Informations de base

Ansible Tower ou sa version open source AWX est également connu sous le nom d'interface utilisateur, tableau de bord et API REST d'Ansible. Avec un contrôle d'accès basé sur les rôles, une planification de tâches et une gestion graphique des inventaires, vous pouvez gérer votre infrastructure Ansible à partir d'une interface moderne. L'API REST de Tower et son 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 de Ansible Tower avec plus de fonctionnalités.

Différences

Selon ceci, les principales différences entre Ansible Tower et AWX sont le support reçu et le fait qu'Ansible Tower dispose de fonctionnalités supplémentaires telles que le contrôle d'accès basé sur les rôles, la prise en charge d'API personnalisées et de workflows définis par l'utilisateur.

Stack technologique

• Interface Web : Il s'agit de l'interface graphique où les utilisateurs peuvent gérer les inventaires, les informations d'identification, 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 scripter 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 : Il s'agit du 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) sur 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 tels que 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 extraire les derniers playbooks lorsque nécessaire.

• Modèles : Les modèles de tâches définissent comment un playbook particulier sera exécuté, en spécifiant l'inventaire, les informations d'identification et d'autres paramètres pour la tâche.

• Informations d'identification : AWX/Tower fournit un moyen sécurisé de gérer et stocker des secrets, tels que des clés SSH, des mots de passe et des jetons API. Ces informations d'identification peuvent être associées à des modèles de tâches afin que les playbooks aient l'accès nécessaire lors de leur exécution.

• Moteur de tâches : C'est là que la magie opère. Le moteur de tâches est basé 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 informations d'identification spécifiées.

• Planificateurs et rappels : Ce sont des fonctionnalités avancées dans AWX/Tower qui permettent de planifier l'exécution de tâches à des moments spécifiques ou déclenchées par des événements externes.

• Notifications : AWX/Tower peut envoyer des notifications en fonction de la réussite 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 reproductible. Rédigés en YAML, les playbooks utilisent le langage d'automatisation déclaratif d'Ansible pour décrire les configurations, les tâches et les étapes à exécuter.

Flux d'exécution des tâches

1. Interaction de l'utilisateur : Un utilisateur peut interagir avec AWX/Tower soit via l'interface Web soit via l'API REST. Ces interfaces offrent un accès frontal à toutes les fonctionnalités proposées par AWX/Tower.

2. Initiation de la tâche :

• L'utilisateur, via l'interface Web ou l'API, lance 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 informations d'identification.

• Lors du lancement de la tâche, une demande est envoyée au backend d'AWX/Tower pour mettre la tâche en file d'attente pour son 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 une tâche lancée, un message est envoyé au moteur de tâches en utilisant RabbitMQ.

• Redis agit comme backend pour la file d'attente des tâches, gérant les tâches en attente d'exécution.

4. Exécution de la tâche :

• Le moteur de tâches récupère la tâche en file d'attente. Il récupère les informations nécessaires de la base de données concernant le playbook associé à la tâche, l'inventaire et les informations d'identification.

• 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 informations d'identification fournies.

• Pendant l'exécution du playbook, sa sortie d'exécution (logs, faits, etc.) est capturée et stockée dans la base de données.

5. Résultats de la tâche :

• Une fois l'exécution du playbook terminée, les résultats (succès, échec, logs) 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 de la tâche, 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 dynamiquement récupérés à partir de systèmes externes, permettant à AWX/Tower de récupérer des hôtes à partir de sources telles que AWS, Azure, VMware, et plus encore.

• Les projets (playbooks) peuvent être extraits 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 d'un laboratoire AWX pour les tests

En suivant la documentation 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é est appelé Administrateur Système. Toute personne ayant ce rôle peut modifier n'importe quoi.

Dans le cadre d'une revue de sécurité white box, vous auriez besoin du rôle d'Auditeur Système, qui permet de visualiser 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.

Étendez ceci pour obtenir une description détaillée des rôles disponibles

1. Administrateur Système:

• Il s'agit du rôle superutilisateur avec des autorisations pour accéder et modifier toutes les ressources du système.

• Ils peuvent gérer toutes les organisations, équipes, projets, inventaires, modèles de tâches, etc.

2. Auditeur Système:

• Les utilisateurs avec ce rôle peuvent visualiser 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 autorisations spécifiques.

• Exécuter: Peut exécuter des modèles de tâches au sein de l'organisation.

• Lire: Peut visualiser 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 tâche.

• Mettre à jour: Peut mettre à jour le projet en utilisant le SCM (contrôle de source).

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 tâche.

• Lire: Accès en lecture seule.

6. Rôles de Modèle de Tâche:

• Admin: Peut gérer et modifier le modèle de tâche.

• Exécuter: Peut exécuter la tâche.

• Lire: Accès en lecture seule.

7. Rôles de Credential:

• Admin: Peut gérer et modifier les informations d'identification.

• Utiliser: Peut utiliser les informations d'identification dans des modèles de tâches ou d'autres ressources pertinentes.

• Lire: Accès en lecture seule.

8. Rôles d'Équipe:

• Membre: Fait partie de l'équipe mais sans autorisations 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 flux de travail.

• Exécuter: Peut exécuter le flux de travail.

• Lire: Accès en lecture seule.