become dans Ansible : comprendre l'élévation de privilèges

Depuis la section 3, on écrit become: yes presque par réflexe, sans jamais s’y arrêter. Le moment est venu de comprendre précisément ce que ça fait, et surtout comment l’utiliser avec plus de finesse qu’un simple interrupteur « tout ou rien » au niveau du play.

Ce que `become` fait concrètement

become demande à Ansible d’exécuter une tâche avec des privilèges élevés — l’équivalent de sudo devant une commande, mais géré directement par Ansible plutôt que tapé manuellement.

- name: Installer Apache
  ansible.builtin.apt:
    name: apache2
    state: present
  become: yes

ans become: yes, cette tâche échouerait sur la plupart des systèmes : installer un paquet nécessite les droits root, et un compte de connexion standard (comme alice, créée en section 7) ne les a pas par défaut.

Au niveau du play vs au niveau de la tâche

Jusqu’ici, on l’a systématiquement placé au niveau du play, pour que toutes les tâches en bénéficient :

---
- name: Déployer Apache
  hosts: webservers
  become: yes    # s'applique à TOUTES les tâches de ce play

  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present

    - name: Vérifier la version
      ansible.builtin.command: apache2 -v

Mais on peut aussi le préciser tâche par tâche, si seules certaines actions ont réellement besoin de privilèges élevés :

---
- name: Déployer Apache avec become ciblé
  hosts: webservers

  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present
      become: yes

    - name: Vérifier la version (pas besoin de droits élevés)
      ansible.builtin.command: apache2 -v

Pourquoi limiter `become` au strict nécessaire

C’est une question de principe de sécurité connu sous le nom de moindre privilège : n’accorder que les droits réellement nécessaires, jamais plus. Un playbook qui met become: yes au niveau du play par réflexe, même sur des tâches qui n’en ont pas besoin, élargit inutilement la surface où une erreur (ou un module mal utilisé) pourrait avoir des conséquences plus graves qu’attendu.

En pratique, dans un lab de formation avec un compte root comme on l’a fait jusqu’ici, la différence est peu visible. Mais dans un vrai projet Nordika, où les connexions se font avec un compte nominal (comme alice, créée en section 7) plutôt qu’avec root directement, cette granularité devient réellement importante.

`become_user` : devenir un autre utilisateur que root

Par défaut, become élève vers root. Mais on peut cibler un autre compte, par exemple pour exécuter une commande avec l’identité d’un compte de service applicatif :

- name: Lancer une commande en tant qu'utilisateur applicatif
  ansible.builtin.command: /opt/nordika/app/manage.sh status
  become: yes
  become_user: nordika_app

`become_method` : sudo n’est pas la seule méthode

sudo est la méthode par défaut, mais Ansible en supporte d’autres selon le contexte système (su, doas sur certains BSD, pbrun…). Rarement nécessaire à changer, mais bon à savoir si votre infrastructure a des contraintes particulières :

- name: Élévation via su plutôt que sudo
  ansible.builtin.apt:
    name: apache2
    state: present
  become: yes
  become_method: su

Diagnostiquer un problème de privilèges

Un message d’erreur du type Missing sudo password ou permission denied indique presque toujours un souci de become. Deux réflexes de vérification :

# Vérifier que le compte de connexion a bien les droits sudo attendus
ansible webservers -i inventaire.yaml -m command -a "whoami" --become

# Si le compte a besoin d'un mot de passe sudo (pas notre cas avec root, mais fréquent avec un compte nominal)
ansible-playbook playbook_apache.yaml -i inventaire.yaml --ask-become-pass

Ce qu’il faut retenir

become: yes élève les privilèges, généralement vers root, l’équivalent Ansible de sudo.
Placé au niveau du play, il s’applique à tout ; placé au niveau d’une tâche, il ne s’applique qu’à elle — préférez le second dès que possible, par principe de moindre privilège.
become_user permet de cibler un autre compte que root ; become_method change l’outil d’élévation sous-jacent, rarement nécessaire à toucher.

Ce que become fait concrètement