10 Berechtigungen und Ausführungskontext in Ansible

10.1 Grundlagen der Rechteverwaltung in Ansible

Ansible führt Aufgaben auf Zielsystemen unter bestimmten Benutzerkonten aus. Die korrekte Konfiguration von Ausführungskontext und Berechtigungen ist entscheidend für eine erfolgreiche und sichere Automatisierung. Dieses Kapitel behandelt die technischen Mechanismen zur Steuerung von Benutzerrechten bei der Playbook-Ausführung.

10.1.1 Ansible-Ausführungsmodell

Ansible unterscheidet zwischen verschiedenen Ausführungsebenen:

10.2 Steuerung des Ausführungskontexts

10.2.1 Der remote_user Parameter

Der remote_user definiert, unter welchem Benutzerkonto sich Ansible auf den Zielsystemen anmeldet und Aufgaben ausführt.

---
- name: Playbook mit definiertem Remote-User
  hosts: webservers
  remote_user: ansible_user
  tasks:
    - name: Prüfe Systemstatus
      command: uptime

Anwendungsebenen:

10.2.2 Privilegien-Eskalation mit become

Der become-Mechanismus ermöglicht die temporäre Erhöhung von Berechtigungen während der Aufgabenausführung.

10.2.2.1 Grundlegende become-Konfiguration

---
- name: Systemkonfiguration mit erhöhten Rechten
  hosts: all
  become: yes
  become_method: sudo
  become_user: root
  tasks:
    - name: Installiere System-Paket
      package:
        name: htop
        state: present

10.2.2.2 Granulare Rechtevergabe pro Task

---
- name: Gemischte Berechtigungen
  hosts: all
  tasks:
    - name: Aufgabe als normaler Benutzer
      debug:
        msg: "Läuft als: {{ ansible_user_id }}"
    
    - name: Aufgabe mit Root-Rechten
      systemd:
        name: nginx
        state: started
        enabled: yes
      become: yes
      become_user: root
    
    - name: Aufgabe als spezifischer Service-User
      file:
        path: /opt/application/config
        state: directory
        owner: appuser
        group: appgroup
      become: yes
      become_user: appuser

10.2.3 Verfügbare become-Methoden

Ansible unterstützt verschiedene Privilegien-Eskalationsmethoden:

Methode Beschreibung Anwendungsfall
sudo Standard Unix-Privilegien-Eskalation Linux/Unix-Systeme
su Wechsel zu anderem Benutzer Systeme ohne sudo
pbrun PowerBroker Enterprise-Umgebungen
pfexec Solaris-Privilegien Solaris-Systeme
doas OpenBSD-Alternative zu sudo OpenBSD-Systeme
dzdo Centrify DirectAuthorize Enterprise Active Directory 
# Beispiel für verschiedene become-Methoden
- name: Linux mit sudo
  hosts: linux_servers
  become: yes
  become_method: sudo
  become_user: root

- name: Solaris mit pfexec
  hosts: solaris_servers
  become: yes
  become_method: pfexec
  become_user: root

10.3 Sicherheitskonzepte und Best Practices

10.3.1 Prinzip der minimalen Berechtigung

---
- name: Demonstration minimaler Berechtigungen
  hosts: webservers
  tasks:
    # Keine erhöhten Rechte nötig
    - name: Lese Konfigurationsdatei
      slurp:
        src: /etc/hostname
      register: hostname_content
    
    # Nur für diese spezifische Aufgabe
    - name: Starte Webserver-Service
      systemd:
        name: apache2
        state: started
      become: yes
      become_user: root
    
    # Wieder als normaler User
    - name: Prüfe Service-Status
      uri:
        url: "http://{{ inventory_hostname }}"
        method: GET
      delegate_to: localhost

10.3.2 SSH-Schlüssel-basierte Authentifizierung

# ansible.cfg
[defaults]
private_key_file = ~/.ssh/ansible_rsa
host_key_checking = False

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

10.3.3 Sudoers-Konfiguration für Ansible

Beispiel für /etc/sudoers.d/ansible:

# Ansible-User mit NOPASSWD für spezifische Befehle
ansible_user ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/yum

# Für vollständige Automatisierung (weniger sicher)
ansible_user ALL=(ALL) NOPASSWD: ALL

10.3.4 Vault-Integration für sensible Daten

---
- name: Sichere Verwendung von Credentials
  hosts: databases
  vars:
    db_admin_password: "{{ vault_db_admin_password }}"
  tasks:
    - name: Konfiguriere Datenbank-User
      mysql_user:
        name: appuser
        password: "{{ vault_app_db_password }}"
        state: present
      become: yes
      become_user: mysql

10.4 Debugging und Troubleshooting

10.4.1 Überprüfung des aktuellen Ausführungskontexts

---
- name: Debug Benutzerkontext
  hosts: all
  gather_facts: yes
  tasks:
    - name: Zeige aktuellen Benutzer
      debug:
        var: ansible_user_id
    
    - name: Zeige effektive Benutzer-ID
      debug:
        var: ansible_effective_user_id
    
    - name: Zeige Gruppenmitgliedschaften
      debug:
        var: ansible_user_gid
    
    - name: Teste sudo-Berechtigung
      command: sudo -l
      register: sudo_rights
      ignore_errors: yes
    
    - name: Zeige sudo-Rechte
      debug:
        var: sudo_rights.stdout_lines

10.4.2 Häufige Berechtigungsfehler

# Problem: Unzureichende Berechtigung
- name: Fehlgeschlagene Aufgabe ohne become
  systemd:
    name: nginx
    state: restarted
  # ERROR: Failed to restart nginx.service: Access denied

# Lösung: become verwenden
- name: Korrekte Aufgabe mit become
  systemd:
    name: nginx
    state: restarted
  become: yes

10.5 Integration mit AWX/Ansible Automation Platform

Hinweis: Die folgenden Konzepte gelten nur für AWX/Ansible Automation Platform, nicht für Ansible Core.

10.5.1 Credential Types in AWX

{
  "name": "SSH Machine Credential",
  "description": "SSH-basierte Anmeldung für Managed Nodes",
  "fields": [
    {"id": "username", "label": "Username"},
    {"id": "ssh_key_data", "label": "SSH Private Key", "secret": true},
    {"id": "become_method", "label": "Privilege Escalation Method"},
    {"id": "become_username", "label": "Privilege Escalation Username"},
    {"id": "become_password", "label": "Privilege Escalation Password", "secret": true}
  ]
}

10.5.2 RBAC in AWX

AWX implementiert rollenbasierte Zugriffskontrolle (RBAC) mit definierten Rollen: