Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ansible Tower ou sa version open source AWX est également connu comme l'interface utilisateur d'Ansible, le tableau de bord et l'API REST. 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
Following the docs il est possible d'utiliser docker-compose pour exécuter AWX :
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
