Behebung von Ansible-Privilegieneskalationsfehlern mit Become und Sudo

Ansible-Privilegieneskalationsfehler treten normalerweise auf, wenn eine Aufgabe Root-Zugriff benötigt, aber Ihr Verbindungsbenutzer sudo nicht korrekt verwenden kann. Möglicherweise sehen Sie "Permission denied", "Fehlendes Sudo-Passwort" oder eine Aufgabe, die über SSH funktioniert, aber innerhalb eines Playbooks fehlschlägt.

Die Lösung ist in der Regel eine Kombination aus Ansible become-Einstellungen und der Sudoers-Konfiguration des Zielhosts. Dieser Leitfaden zeigt beide Seiten.

Verstehen des Ansible become-Mechanismus

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 Privilegien (z. B. root-Zugriff auf Linux-Systeme). 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 gesamte 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 typischerweise als regulärer, unprivilegierter Benutzer (oft als ansible_user bezeichnet) mit Ihren Remote-Hosts und verwenden dann become, um die Privilegien für Aufgaben, die sie benötigen, vorübergehend zu erhöhen. Dies folgt dem Prinzip der geringsten Privilegien und minimiert die potenziellen Auswirkungen einer Sicherheitsverletzung.

become-Methoden

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

Konfigurieren von become-Einstellungen in Ansible

Ansible bietet mehrere Möglichkeiten, become-Einstellungen zu konfigurieren, von globalen Konfigurationen bis hin zu aufgabenspezifischen Überschreibungen. Das Verständnis dieser Bereiche ist entscheidend für ein effektives Privilegienmanagement.

1. Globale Konfiguration in ansible.cfg

Für allgemeine Anwendungsfälle über viele Playbooks hinweg können Sie standardmäßige become-Parameter in Ihrer ansible.cfg-Datei festlegen. Diese befindet sich normalerweise im 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 ; Setzen Sie auf True, wenn Ansible zur Eingabe des Passworts auffordern soll

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

2. Pro Play oder pro Aufgabe in Playbooks

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

Konfiguration auf Play-Ebene:

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

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

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

Konfiguration auf Aufgabenebene:

---
- 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-gehörende 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 unterschiedliche Privilegieneskalationsstrategien für verschiedene Hosts oder Gruppen angeben können.

hosts.ini-Beispiel:

[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, Gruppenebene oder Hostebene 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 <METHODE>: Gibt die Become-Methode an (z. B. sudo).
• --become-user <BENUTZER>: Gibt den Zielbenutzer an (z. B. root).
• --ask-become-pass oder -K: Fordert während der Ausführung zur Eingabe des become-Passworts auf. Dies ist nützlich zum Testen, 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 sudoers-Datei definiert, wer welche Befehle und als wer ausführen darf. Ein häufiger Eintrag, um einem Ansible-Verbindungsbenutzer (devops_user in diesem Beispiel) zu erlauben, jeden Befehl als jeden Benutzer ohne Passwortabfrage auszuführen, ist:

# /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 aus 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: Die Gewährung 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 hochsicher 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 sudo-Zugriff auf einem Zielhost hat. Stellen Sie eine SSH-Verbindung zum Host als ansible_user her und führen Sie aus:

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

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

# Listen Sie sudo-Berechtigungen für den aktuellen Benutzer auf:
sudo -l

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

Wenn sudo -n whoami ohne Passwortabfrage root zurückgibt, ist Ihre NOPASSWD-Konfiguration wahrscheinlich korrekt. Wenn es nach einem Passwort fragt, fehlt möglicherweise NOPASSWD in Ihrem sudoers-Eintrag oder er ist falsch konfiguriert.

Diagnose von Privilegieneskalationsfehlern

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

1. "Permission denied"

Dies bedeutet normalerweise, dass die Aufgabe als unprivilegierter Verbindungsbenutzer anstelle von root ausgeführt wurde.

Überprüfen Sie das Play oder die Aufgabe:

- name: Installiere Paket, das root erfordert
  ansible.builtin.package:
    name: nginx
    state: present
  become: true

Bestätigen Sie dann, welchen Benutzer Ansible verwendet:

ansible webservers -m ansible.builtin.command -a 'whoami'
ansible webservers -b -m ansible.builtin.command -a 'whoami'

Der zweite Befehl sollte root zurückgeben, wenn sudo funktioniert.

2. "Fehlendes Sudo-Passwort"

Dies tritt auf, wenn der Zielhost ein Sudo-Passwort erfordert, Ansible aber keines erhalten hat.

Für einen interaktiven Durchlauf verwenden Sie:

ansible-playbook site.yml --ask-become-pass

Für die Automatisierung vermeiden Sie es, Klartext-Passwörter im Inventar zu speichern. Verwenden Sie Ansible Vault für ansible_become_password, wenn passwortloses sudo in Ihrer Umgebung nicht erlaubt ist.

ansible-vault encrypt group_vars/webservers/vault.yml

Beispiel für einen verschlüsselten Variablennamen vor der Verschlüsselung:

ansible_become_password: "replace-with-real-password"

3. "Benutzer ist nicht in der sudoers-Datei"

Dies ist ein Konfigurationsproblem des Zielhosts. Ansible kann es nicht beheben, es sei denn, es kann sich bereits als Benutzer mit ausreichenden Berechtigungen verbinden.

Verwenden Sie auf dem Zielhost visudo oder eine Datei unter /etc/sudoers.d/:

devops_user ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/yum

Dies ist enger gefasst als NOPASSWD: ALL, funktioniert aber nur, wenn Ihre Playbooks genau diese Befehle benötigen. Paketmodule können je nach Betriebssystem unterschiedliche Binärdateien aufrufen, also testen Sie sorgfältig.

4. Falscher become_user

Die meisten Linux-Verwaltungsaufgaben verwenden become_user: root. Wenn Sie become_user auf ein Anwendungskonto setzen, fehlen diesem Benutzer möglicherweise die Berechtigungen, um Systemdateien zu ändern oder Dienste zu verwalten.

Verwenden Sie eine schnelle Überprüfung:

- name: Bestätige effektiven Benutzer
  ansible.builtin.command: whoami
  become: true
  changed_when: false

Wenn die Ausgabe nicht der erwartete Benutzer ist, überprüfen Sie Playbook-Variablen, Inventarvariablen und ansible.cfg auf widersprüchliche become_user-Werte.

Eine sichere Checkliste zur Fehlerbehebung

Arbeiten Sie vom Zielhost zurück zum Playbook:

1. Stellen Sie eine SSH-Verbindung zum Host als ansible_user her.
2. Führen Sie sudo -l aus und bestätigen Sie, dass der Benutzer die erforderlichen Rechte hat.
3. Führen Sie sudo -n whoami aus, wenn Sie passwortloses sudo erwarten.
4. Führen Sie ansible all -b -m command -a 'whoami' gegen einen Testhost aus.
5. Fügen Sie -vvv zum fehlschlagenden Playbook-Durchlauf hinzu, wenn der Fehler immer noch unklar ist.

Wichtigste Erkenntnis

Ansible become weist Ansible nur an, Privilegien zu erhöhen. Der Zielhost muss dem Verbindungsbenutzer dennoch erlauben, dies über sudo oder eine andere Become-Methode zu tun. Beheben Sie beide Seiten: Setzen Sie become dort, wo die Aufgabe es benötigt, und überprüfen Sie dann die Sudo-Rechte direkt auf dem Host.