Résolution des erreurs d'escalade de privilèges Ansible à l'aide de Become et Sudo

Ansible est un moteur d'automatisation puissant qui rationalise la gestion de la configuration, le déploiement d'applications et l'orchestration des tâches sur un parc de serveurs. Cependant, l'un des obstacles les plus courants rencontrés par les utilisateurs novices et expérimentés est la gestion des erreurs d'escalade de privilèges. Ces problèmes se manifestent souvent par des messages « permission denied » (permission refusée) lorsqu'Ansible tente d'effectuer des actions nécessitant des droits élevés, telles que l'installation de paquets, la modification de fichiers système ou la gestion de services.

Ce guide complet vous expliquera les subtilités du mécanisme become d'Ansible, son intégration avec sudo pour l'escalade de privilèges, et vous fournira des étapes concrètes pour diagnostiquer et résoudre les problèmes d'authentification connexes. En comprenant et en configurant correctement ces paramètres, vous vous assurerez que vos playbooks Ansible s'exécutent de manière fluide et sécurisée, quelles que soient les exigences d'accès du système cible.

Comprendre le mécanisme become d'Ansible

Fondamentalement, Ansible fonctionne en se connectant aux hôtes cibles, généralement via SSH, et en exécutant des commandes en tant qu'utilisateur distant. Cependant, de nombreuses tâches administratives nécessitent des privilèges élevés (par exemple, un accès root sur les systèmes Linux). C'est là qu'intervient la fonctionnalité become d'Ansible. Le mécanisme become permet à Ansible de « devenir » un autre utilisateur, généralement root, pour exécuter des tâches spécifiques ou des playbooks entiers avec des autorisations élevées.

Pourquoi become est nécessaire

Exécuter toutes les tâches Ansible directement en tant qu'utilisateur root est généralement une mauvaise pratique de sécurité. Au lieu de cela, vous vous connectez généralement à vos hôtes distants en tant qu'utilisateur ordinaire et non privilégié (souvent appelé ansible_user), puis vous utilisez become pour augmenter temporairement les privilèges pour les tâches qui en ont besoin. Ceci respecte le principe du moindre privilège, minimisant ainsi l'impact potentiel d'une faille de sécurité.

Méthodes become

Ansible prend en charge plusieurs méthodes d'escalade de privilèges, chacune correspondant à différents utilitaires système. La méthode la plus courante et la plus largement utilisée, en particulier sur les systèmes Linux/Unix, est sudo (Substitute User Do). D'autres méthodes incluent su, pbrun, doas, et plus encore, mais ce guide se concentrera principalement sur sudo en raison de sa prévalence.

Configuration des paramètres become dans Ansible

Ansible offre plusieurs façons de configurer les paramètres become, allant des configurations globales aux remplacements spécifiques aux tâches. Comprendre ces portées est crucial pour une gestion efficace des privilèges.

1. Configuration globale dans ansible.cfg

Pour les cas d'utilisation généraux dans de nombreux playbooks, vous pouvez définir les paramètres become par défaut dans votre fichier ansible.cfg. Celui-ci se trouve généralement dans le répertoire où vous exécutez Ansible, ~/.ansible.cfg, ou /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Définir sur True si vous souhaitez qu'Ansible demande le mot de passe

• become=True: Active l'escalade de privilèges par défaut pour tous les playbooks.
• become_method=sudo: Spécifie sudo comme méthode d'escalade de privilèges.
• become_user=root: Spécifie root comme utilisateur cible à devenir.
• become_ask_pass=False: Contrôle si Ansible doit demander le mot de passe become. Définir sur True si vous ne fournissez pas le mot de passe par d'autres moyens.

2. Par Playbook ou Par Tâche dans les Playbooks

Pour un contrôle plus granulaire, les paramètres become peuvent être définis directement dans vos playbooks, soit au niveau du playbook (affectant toutes les tâches de ce playbook), soit au niveau de la tâche individuelle.

Configuration au niveau du Playbook :

---
- name: Installer Nginx avec des privilèges élevés
  hosts: webservers
  become: yes          # Activer become pour toutes les tâches de ce playbook
  become_user: root
  become_method: sudo

  tasks:
    - name: S'assurer que Nginx est installé
      ansible.builtin.apt:
        name: nginx
        state: present
      # Cette tâche s'exécutera en tant que root via sudo

    - name: Copier la configuration Nginx
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Cette tâche s'exécutera également en tant que root via sudo

Configuration au niveau de la Tâche :

---
- name: Gérer les fichiers en tant qu'utilisateurs différents
  hosts: all

  tasks:
    - name: Créer un fichier appartenant à l'utilisateur ansible_user (par défaut)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Créer un fichier appartenant à root en utilisant become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # Seule cette tâche utilisera become
      become_user: root
      become_method: sudo

3. Via les variables d'inventaire

Les paramètres become peuvent également être définis dans votre inventaire Ansible, vous permettant de spécifier différentes stratégies d'escalade de privilèges pour différents hôtes ou groupes.

Exemple hosts.ini :

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=devops_user
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root

Ici, ansible_become, ansible_become_method et ansible_become_user sont des variables d'inventaire qui correspondent aux paramètres become. Elles peuvent être définies au niveau all:vars, au niveau du groupe ou au niveau de l'hôte.

4. Utilisation des arguments CLI de ansible-playbook

Pour des remplacements rapides ou une exécution interactive, vous pouvez transmettre les paramètres become directement via la ligne de commande :

• --become ou -b: Active become.
• --become-method <METHOD>: Spécifie la méthode become (par exemple, sudo).
• --become-user <USER>: Spécifie l'utilisateur cible (par exemple, root).
• --ask-become-pass ou -K: Demande le mot de passe become pendant l'exécution. Ceci est utile pour les tests, mais généralement pas pour l'automatisation.

Exemple :

ansible-playbook my_playbook.yml --become --become-user root --ask-become-pass

Assurer les droits sudo pour l'utilisateur become

Configurer correctement become dans Ansible n'est que la moitié du chemin. L'utilisateur avec lequel Ansible se connecte (l'ansible_user) doit disposer des privilèges sudo nécessaires sur l'hôte cible pour devenir l'become_user. Ceci est configuré sur l'hôte cible dans le fichier /etc/sudoers ou un fichier sous /etc/sudoers.d/.

Configuration de sudoers

Le fichier sudoers définit qui peut exécuter quelles commandes, et en tant que qui. Une entrée courante pour permettre à un utilisateur de connexion Ansible (devops_user dans cet exemple) d'exécuter n'importe quelle commande en tant que n'importe quel utilisateur sans invite de mot de passe est :

# /etc/sudoers.d/devops
devops_user ALL=(ALL) NOPASSWD: ALL

Explication :

• devops_user: Le nom d'utilisateur avec lequel Ansible se connecte (ansible_user).
• ALL: Cet utilisateur peut exécuter des commandes depuis n'importe quel terminal.
• (ALL): Cet utilisateur peut exécuter des commandes en tant que n'importe quel utilisateur.
• NOPASSWD:: Spécifie qu'aucun mot de passe n'est requis pour les opérations sudo.
• ALL: Cet utilisateur peut exécuter toutes les commandes.

Avertissement : Accorder NOPASSWD: ALL donne à l'ansible_user un accès root sans restriction et sans mot de passe, ce qui peut constituer un risque de sécurité important. Utilisez ceci uniquement si cela est vraiment nécessaire et assurez-vous que les informations d'identification de votre ansible_user sont hautement sécurisées. Pour une sécurité plus stricte, vous pouvez spécifier les commandes exactes ou les ensembles de commandes que l'utilisateur est autorisé à exécuter.

Vérification de l'accès sudo

Avant d'exécuter votre playbook, vous pouvez vérifier manuellement si votre ansible_user dispose d'un accès sudo sur un hôte cible. Connectez-vous en SSH à l'hôte en tant qu'ansible_user et exécutez :

# Vérifier si vous pouvez utiliser sudo vers root sans mot de passe
sudo -n whoami

# Si un mot de passe est requis, vous serez invité. Testez avec une commande simple :
sudo whoami

# Lister les privilèges sudo pour l'utilisateur actuel :
sudo -l

# Lister les privilèges sudo pour un utilisateur spécifique (par exemple, devops_user) :
sudo -l -U devops_user

Si sudo -n whoami renvoie root sans invite de mot de passe, votre configuration NOPASSWD est probablement correcte. S'il demande un mot de passe, votre entrée sudoers pourrait manquer NOPASSWD ou être mal configurée.

Diagnostic des erreurs d'escalade de privilèges

Ansible fournit généralement des messages d'erreur informatifs, mais les problèmes liés aux privilèges peuvent parfois être cryptiques. Voici les erreurs courantes et leurs solutions :

1. « permission denied » ou "