Beheben von Ansible Berechtigungseskalationsfehlern mit Become und Sudo

Ansible ist eine leistungsstarke Automatisierungs-Engine, die die Konfigurationsverwaltung, Anwendungsbereitstellung und Task-Orchestrierung über eine Flotte von Servern hinweg rationalisiert. Eine der häufigsten Hürden, mit denen neue und erfahrene Benutzer konfrontiert sind, ist jedoch der Umgang mit Fehlern bei der Berechtigungseskalation. Diese Probleme äußern sich oft als "Zugriff verweigert"-Meldungen, wenn Ansible versucht, Aktionen auszuführen, die erhöhte Rechte erfordern, wie z. B. die Installation von Paketen, die Änderung von Systemdateien oder die Verwaltung von Diensten.

Diese umfassende Anleitung führt Sie durch die Feinheiten des become-Mechanismus von Ansible, wie er mit sudo zur Berechtigungseskalation integriert wird, und bietet umsetzbare Schritte zur Diagnose und Behebung verwandter Authentifizierungsprobleme. Durch das Verständnis und die korrekte Konfiguration dieser Einstellungen können Sie sicherstellen, dass Ihre Ansible Playbooks reibungslos und sicher ausgeführt werden, unabhängig von den Zugriffsanforderungen des Zielsystems.

Verstehen des become-Mechanismus von Ansible

Im Kern verbindet sich Ansible mit Zielhosts, typischerweise über SSH, und führt Befehle als Remote-Benutzer aus. Viele administrative Aufgaben erfordern jedoch erhöhte Berechtigungen (z. B. root-Zugriff unter Linux-Systemen). Hier kommt die become-Funktion von Ansible ins Spiel. Der become-Mechanismus ermöglicht es Ansible, ein anderer Benutzer zu "werden", normalerweise root, um bestimmte Aufgaben oder ganze Plays mit erhöhten Berechtigungen auszuführen.

Warum become notwendig ist

Alle Ansible-Aufgaben direkt als root-Benutzer auszuführen, ist im Allgemeinen eine schlechte Sicherheitspraxis. Stattdessen verbinden Sie sich normalerweise mit Ihren Remote-Hosts als regulärer, nicht privilegierter Benutzer (oft als ansible_user bezeichnet) und verwenden dann become, um Berechtigungen für Aufgaben, die diese erfordern, vorübergehend zu eskalieren. Dies entspricht dem Prinzip der geringsten Rechte und minimiert die potenziellen Auswirkungen einer Sicherheitsverletzung.

become-Methoden

Ansible unterstützt mehrere Methoden zur Berechtigungseskalation, die jeweils unterschiedlichen System-Utilities entsprechen. Die gebräuchlichste und am weitesten verbreitete Methode, insbesondere unter Linux/Unix-Systemen, ist sudo (Substitute User Do). Andere Methoden umfassen su, pbrun, doas und mehr, aber diese Anleitung konzentriert sich aufgrund seiner Verbreitung hauptsächlich auf sudo.

Konfigurieren von become-Einstellungen in Ansible

Ansible bietet mehrere Möglichkeiten zur Konfiguration von become-Einstellungen, von globalen Konfigurationen bis hin zu aufgabenbezogenen Überschreibungen. Das Verständnis dieser Geltungsbereiche ist entscheidend für eine effektive Berechtigungsverwaltung.

1. Globale Konfiguration in ansible.cfg

Für allgemeine Anwendungsfälle über viele Playbooks hinweg können Sie Standardparameter für become in Ihrer ansible.cfg-Datei festlegen. Diese befindet sich typischerweise in dem Verzeichnis, in dem Sie Ansible ausführen: ~/.ansible.cfg oder /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Auf True setzen, wenn Ansible zur Eingabe des Passworts aufgefordert werden soll

• become=True: Aktiviert die Berechtigungseskalation standardmäßig für alle Plays.
• become_method=sudo: Gibt sudo als Methode zur Berechtigungseskalation an.
• become_user=root: Gibt root als Zielbenutzer an, zu dem gewechselt werden soll.
• become_ask_pass=False: Steuert, ob Ansible zur become-Passwortaufforderung auffordern soll. Auf True setzen, wenn Sie das Passwort nicht auf andere Weise angeben.

2. Pro Play oder Pro Aufgabe in Playbooks

Für eine feinere Steuerung können become-Einstellungen direkt in Ihren Playbooks definiert werden, entweder auf Play-Ebene (betrifft alle Aufgaben in diesem Play) oder auf Ebene einzelner Aufgaben.

Konfiguration auf Play-Ebene:

---
- name: Installiere Nginx mit erhöhten Rechten
  hosts: webservers
  become: yes          # Become für alle Aufgaben in diesem Play aktivieren
  become_user: root
  become_method: sudo

  tasks:
    - name: Stelle sicher, dass Nginx installiert ist
      ansible.builtin.apt:
        name: nginx
        state: present
      # Diese Aufgabe wird über sudo als root ausgeführt

    - name: Kopiere Nginx-Konfiguration
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Diese Aufgabe wird ebenfalls über sudo als root ausgeführt

Konfiguration auf Aufgaben-Ebene:

---
- name: Verwalte Dateien als verschiedene Benutzer
  hosts: all

  tasks:
    - name: Erstelle eine Datei als ansible_user (Standard)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Erstelle eine root-geführte Datei mit become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # Nur diese Aufgabe verwendet become
      become_user: root
      become_method: sudo

3. Über Inventarvariablen

become-Einstellungen können auch in Ihrem Ansible-Inventar definiert werden, sodass Sie für verschiedene Hosts oder Gruppen unterschiedliche Strategien zur Berechtigungseskalation festlegen können.

Beispiel 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

Hier sind ansible_become, ansible_become_method und ansible_become_user Inventarvariablen, die den become-Einstellungen entsprechen. Sie können auf der Ebene all:vars, auf Gruppenebene oder auf Host-Ebene festgelegt werden.

4. Verwendung von ansible-playbook CLI-Argumenten

Für schnelle Überschreibungen oder interaktive Ausführung können Sie become-Parameter direkt über die Befehlszeile übergeben:

• --become oder -b: Aktiviert become.
• --become-method <METHOD>: Gibt die become-Methode an (z. B. sudo).
• --become-user <USER>: Gibt den Zielbenutzer an (z. B. root).
• --ask-become-pass oder -K: Fordert zur Eingabe des become-Passworts während der Ausführung auf. Dies ist nützlich für Tests, aber im Allgemeinen nicht für die Automatisierung.

Beispiel:

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

Sicherstellen von sudo-Rechten für den become-Benutzer

Die korrekte Konfiguration von become in Ansible ist nur die halbe Miete. Der Benutzer, mit dem sich Ansible verbindet (der ansible_user), muss die erforderlichen sudo-Berechtigungen auf dem Zielhost haben, um zum become_user zu werden. Dies wird auf dem Zielhost in der Datei /etc/sudoers oder einer Datei unter /etc/sudoers.d/ konfiguriert.

Konfigurieren von sudoers

Die Datei sudoers definiert, wer welche Befehle ausführen darf und als wer. Ein gängiger Eintrag, um einem Ansible-Verbindungsbenutzer (devops_user in diesem Beispiel) zu erlauben, jeden Befehl als jeder Benutzer ohne Passwortaufforderung auszuführen, lautet:

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

Erklärung:

• devops_user: Der Benutzername, mit dem sich Ansible verbindet (ansible_user).
• ALL: Dieser Benutzer kann Befehle von jedem Terminal ausführen.
• (ALL): Dieser Benutzer kann Befehle als jeder Benutzer ausführen.
• NOPASSWD:: Gibt an, dass für sudo-Operationen kein Passwort erforderlich ist.
• ALL: Dieser Benutzer kann alle Befehle ausführen.

Warnung: Das Gewähren von NOPASSWD: ALL gibt dem ansible_user uneingeschränkten Root-Zugriff ohne Passwort, was ein erhebliches Sicherheitsrisiko darstellen kann. Verwenden Sie dies nur, wenn es wirklich notwendig ist, und stellen Sie sicher, dass die Anmeldeinformationen Ihres ansible_user hochgradig sicher sind. Für strengere Sicherheit können Sie genaue Befehle oder Befehlssätze angeben, die der Benutzer ausführen darf.

Überprüfen des sudo-Zugriffs

Bevor Sie Ihr Playbook ausführen, können Sie manuell überprüfen, ob Ihr ansible_user über sudo-Zugriff auf einem Zielhost verfügt. Melden Sie sich per SSH als ansible_user auf dem Host an und führen Sie aus:

# Überprüfen Sie, ob Sie ohne Passwort zu root sudo können
sudo -n whoami

# Wenn ein Passwort erforderlich ist, werden Sie aufgefordert. Testen Sie mit einem einfachen Befehl:
sudo whoami

# Liste der sudo-Berechtigungen für den aktuellen Benutzer auf:
sudo -l

# Liste der sudo-Berechtigungen für einen bestimmten Benutzer (z. B. devops_user) auf:
sudo -l -U devops_user

Wenn sudo -n whoami root ohne Passwortaufforderung zurückgibt, ist Ihre NOPASSWD-Konfiguration wahrscheinlich korrekt. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, fehlt möglicherweise NOPASSWD in Ihrem sudoers-Eintrag oder er ist falsch konfiguriert.

Diagnose von Berechtigungseskalationsfehlern

Ansible liefert normalerweise informative Fehlermeldungen, aber berechtigungsbezogene Probleme können manchmal kryptisch sein. Hier sind häufige Fehler und ihre Lösungen:

1. "permission denied" oder