Devenir `root` ou un autre utilisateur (`become`, `become_user`)

Gestion des privilèges dans Ansible : la puissance de `become`

Dans le monde de l'administration système, de nombreuses tâches nécessitent des droits d'accès élevés, typiquement ceux de l'utilisateur `root` (ou superutilisateur). Installer des logiciels, modifier des fichiers de configuration système, gérer des services ou redémarrer une machine sont autant d'opérations qui requièrent une élévation de privilèges. Ansible, en tant qu'outil d'automatisation de ces tâches, doit fournir un mécanisme sécurisé et flexible pour gérer ces situations. C'est là qu'intervient la directive `become` et ses corollaires comme `become_user` et `become_method`.

Le principe de `become` (qui signifie "devenir" en anglais) est de permettre à une tâche ou à un ensemble de tâches de s'exécuter avec les privilèges d'un autre utilisateur que celui utilisé pour la connexion SSH initiale. Le cas le plus courant est de se connecter en tant qu'utilisateur normal (par exemple, `ansible_user`) puis d'utiliser `become` pour exécuter des commandes en tant que `root` via des outils comme `sudo` ou `su`.

Cette section explore en détail comment utiliser `become` pour l'escalade de privilèges dans vos playbooks Ansible. Nous verrons où placer cette directive (au niveau du jeu ou de la tâche), comment spécifier l'utilisateur cible avec `become_user`, et comment configurer la méthode d'escalade avec `become_method`. Maîtriser ces concepts est indispensable pour automatiser des scénarios d'administration complets et sécurisés.

La directive `become` : activer l'escalade de privilèges

La directive la plus fondamentale pour l'élévation de privilèges est `become`. Sa valeur est un booléen (`true` ou `false`). Lorsque `become: true` est spécifié, Ansible tentera d'exécuter la tâche ou l'ensemble des tâches du jeu avec des privilèges escaladés.

Vous pouvez définir `become` à deux niveaux principaux :

• Au niveau du jeu (play) : Si `become: true` est défini au niveau du jeu, toutes les tâches de ce jeu tenteront de s'exécuter avec des privilèges escaladés, sauf si une tâche individuelle le surcharge explicitement avec `become: false`. C'est utile lorsque la majorité des tâches d'un jeu nécessitent des droits `root`.
• Au niveau de la tâche (task) : Vous pouvez spécifier `become: true` ou `become: false` pour une tâche individuelle. Cela permet un contrôle plus granulaire et a priorité sur la configuration du jeu. C'est utile si seulement quelques tâches spécifiques dans un jeu nécessitent une élévation.

Par défaut, si `become: true` est activé, Ansible essaiera d'utiliser la méthode `sudo` pour devenir l'utilisateur `root`. Voici un exemple simple :

- name: Jeu nécessitant des droits root pour toutes les tâches
  hosts: webservers
  become: true  # S'applique à toutes les tâches ci-dessous
  tasks:
    - name: Installer Nginx
      apt:
        name: nginx
        state: present

    - name: Démarrer le service Nginx
      service:
        name: nginx
        state: started

Dans cet exemple, Ansible se connectera au(x) `webservers` avec l'utilisateur SSH configuré, puis pour chaque tâche, il utilisera `sudo` (par défaut) pour exécuter les commandes du module `apt` et `service` en tant que `root`.

Il est important de noter que l'utilisateur avec lequel Ansible se connecte via SSH doit avoir les droits `sudo` configurés sur les machines gérées pour que `become: true` (avec la méthode `sudo`) fonctionne. Si `sudo` requiert un mot de passe et que vous ne l'avez pas configuré pour être sans mot de passe pour cet utilisateur, Ansible vous demandera le mot de passe de `sudo` lors de l'exécution du playbook via l'option `--ask-become-pass` (ou `-K`).

Spécifier l'utilisateur et la méthode : `become_user` et `become_method`

Si vous avez besoin de devenir un utilisateur autre que `root`, ou si vous devez utiliser une méthode d'escalade de privilèges différente de `sudo`, Ansible vous offre les directives `become_user` et `become_method`.

- name: Exécuter une tâche en tant qu'utilisateur applicatif
  hosts: appservers
  tasks:
    - name: Redémarrer l'application Tomcat
      command: /opt/tomcat/bin/shutdown.sh && /opt/tomcat/bin/startup.sh
      become: true
      become_user: tomcat

• `sudo` (par défaut) : Utilise la commande `sudo`.
• `su` : Utilise la commande `su`. Un mot de passe pour l'utilisateur cible (`become_user`) sera généralement requis.
• `pbrun` : Pour PowerBroker.
• `pfexec` : Pour le Profile-Based Execution de Solaris.
• `doas` : Pour la commande `doas` (OpenBSD).
• Et d'autres spécifiques à des systèmes ou des outils (ex: `runas` pour Windows, `enable` pour les équipements réseau).

- name: Jeu utilisant la méthode su pour devenir root
  hosts: legacy_systems
  become: true
  become_method: su
  # Par défaut, become_user sera root si non spécifié avec su
  tasks:
    - name: Vérifier la version du kernel
      command: uname -r

Ces directives (`become_user`, `become_method`) peuvent également être définies au niveau du jeu ou de la tâche, avec la même logique de priorité que `become` (la configuration de la tâche l'emporte sur celle du jeu). Elles peuvent aussi être définies globalement dans le fichier de configuration `ansible.cfg` ou via des variables d'inventaire pour des groupes ou des hôtes spécifiques, offrant une grande flexibilité.

Considérations et bonnes pratiques pour l'utilisation de `become`

L'utilisation de `become` est puissante, mais elle doit être gérée avec soin. Voici quelques considérations et bonnes pratiques :

• Principe du moindre privilège : N'utilisez `become: true` que lorsque c'est absolument nécessaire. Si une tâche peut être accomplie sans droits élevés, exécutez-la sans `become`. Limitez la portée de `become` à des tâches spécifiques plutôt qu'à des jeux entiers si possible.
• Configuration `sudoers` : Assurez-vous que votre fichier `sudoers` sur les machines gérées est correctement configuré pour permettre à l'utilisateur de connexion SSH d'exécuter les commandes nécessaires sans mot de passe (option `NOPASSWD`), ou soyez prêt à fournir le mot de passe via `--ask-become-pass`. Configurer `sudo` pour des commandes spécifiques est plus sécurisé que d'accorder des droits `sudo` complets.
• Idempotence et `become` : Les modules Ansible sont conçus pour être idempotents. Même si une tâche s'exécute avec `become`, elle ne devrait apporter des modifications que si l'état désiré n'est pas déjà atteint.
• Sécurité des mots de passe : Evitez de stocker des mots de passe en clair dans vos playbooks. Si un mot de passe est requis pour `become` (par exemple avec `su` ou si `sudo` le demande), utilisez l'option `--ask-become-pass` ou des solutions de gestion de secrets comme Ansible Vault.
• Testez rigoureusement : Testez toujours vos playbooks utilisant `become` dans un environnement de non-production pour vous assurer qu'ils se comportent comme prévu et n'ont pas d'effets de bord indésirables dus à une mauvaise utilisation des privilèges.
• Documentation : Documentez clairement pourquoi `become` est utilisé pour une tâche ou un jeu particulier, et quel utilisateur (`become_user`) et quelle méthode (`become_method`) sont employés.

En résumé, `become` et ses directives associées sont des outils essentiels pour l'automatisation de tâches d'administration système avec Ansible. Une utilisation judicieuse et sécurisée de ces fonctionnalités vous permettra de gérer efficacement les privilèges nécessaires pour maintenir vos systèmes dans l'état désiré. Comprendre comment Ansible interagit avec les mécanismes d'escalade de privilèges de vos systèmes d'exploitation cibles est la clé pour une automatisation réussie et fiable.