Ansible Tower / AWX / Automation controller Security
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
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.
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.
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.
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.
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.
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 :
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.
Last updated