Risoluzione degli errori di escalation dei privilegi di Ansible utilizzando Become e Sudo

Ansible è un potente motore di automazione che semplifica la gestione della configurazione, il deployment delle applicazioni e l'orchestrazione dei task su una flotta di server. Tuttavia, uno degli ostacoli più comuni che gli utenti, sia nuovi che esperti, incontrano è la gestione degli errori di escalation dei privilegi. Questi problemi si manifestano spesso come messaggi "permission denied" (permesso negato) quando Ansible tenta di eseguire azioni che richiedono privilegi elevati, come l'installazione di pacchetti, la modifica di file di sistema o la gestione dei servizi.

Questa guida completa ti accompagnerà attraverso le complessità del meccanismo become di Ansible, come si integra con sudo per l'escalation dei privilegi e fornirà passaggi attuabili per diagnosticare e risolvere i relativi problemi di autenticazione. Comprendendo e configurando correttamente queste impostazioni, puoi garantire che i tuoi playbook Ansible vengano eseguiti in modo fluido e sicuro, indipendentemente dai requisiti di accesso del sistema di destinazione.

Comprensione del meccanismo become di Ansible

Nella sua essenza, Ansible opera connettendosi agli host di destinazione, tipicamente tramite SSH, ed eseguendo comandi come utente remoto. Molti task amministrativi, tuttavia, richiedono privilegi elevati (ad esempio, accesso root sui sistemi Linux). È qui che entra in gioco la funzionalità become di Ansible. Il meccanismo become consente ad Ansible di "diventare" un altro utente, di solito root, per eseguire task specifici o intere playbook con permessi elevati.

Perché become è necessario

Eseguire tutti i task di Ansible direttamente come utente root è generalmente una cattiva pratica di sicurezza. Invece, di solito ti connetti ai tuoi host remoti come utente normale e non privilegiato (spesso definito ansible_user) e poi usi become per aumentare temporaneamente i privilegi per i task che li richiedono. Ciò aderisce al principio del privilegio minimo, riducendo al minimo l'impatto potenziale di una violazione della sicurezza.

Metodi become

Ansible supporta diversi metodi per l'escalation dei privilegi, ognuno corrispondente a diverse utility di sistema. Il metodo più comune e ampiamente utilizzato, specialmente sui sistemi Linux/Unix, è sudo (Substitute User Do). Altri metodi includono su, pbrun, doas e altri, ma questa guida si concentrerà principalmente su sudo data la sua prevalenza.

Configurazione delle impostazioni become in Ansible

Ansible offre molteplici modi per configurare le impostazioni become, dalle configurazioni globali alle sovrascritture specifiche del task. La comprensione di questi ambiti è cruciale per una gestione efficace dei privilegi.

1. Configurazione globale in ansible.cfg

Per casi d'uso generali in molti playbook, puoi impostare i parametri become predefiniti nel tuo file ansible.cfg. Questo si trova tipicamente nella directory in cui esegui Ansible, ~/.ansible.cfg, o /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Imposta su True se desideri che Ansible chieda la password

• become=True: Abilita l'escalation dei privilegi per impostazione predefinita per tutte le playbook.
• become_method=sudo: Specifica sudo come metodo per l'escalation dei privilegi.
• become_user=root: Specifica root come utente di destinazione da cui diventare.
• become_ask_pass=False: Controlla se Ansible deve richiedere la password become. Imposta su True se non fornisci la password tramite altri mezzi.

2. Per playbook o per task nei Playbook

Per un controllo più granulare, le impostazioni become possono essere definite direttamente all'interno dei tuoi playbook, sia a livello di playbook (influenzando tutti i task in quella playbook) sia a livello di singolo task.

Configurazione a livello di playbook:

---
- name: Installa Nginx con privilegi elevati
  hosts: webservers
  become: yes          # Abilita become per tutti i task in questa playbook
  become_user: root
  become_method: sudo

  tasks:
    - name: Assicura che Nginx sia installato
      ansible.builtin.apt:
        name: nginx
        state: present
      # Questo task verrà eseguito come root tramite sudo

    - name: Copia configurazione Nginx
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Anche questo task verrà eseguito come root tramite sudo

Configurazione a livello di task:

---
- name: Gestisci file come utenti diversi
  hosts: all

  tasks:
    - name: Crea un file come ansible_user (predefinito)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Crea un file di proprietà di root usando become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # Solo questo task utilizzerà become
      become_user: root
      become_method: sudo

3. Tramite variabili di inventario

Le impostazioni become possono anche essere definite nel tuo inventario Ansible, consentendoti di specificare diverse strategie di escalation dei privilegi per host o gruppi diversi.

Esempio 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

Qui, ansible_become, ansible_become_method e ansible_become_user sono variabili di inventario che corrispondono alle impostazioni become. Possono essere impostate a livello di all:vars, a livello di gruppo o a livello di host.

4. Utilizzo degli argomenti CLI di ansible-playbook

Per sovrascritture rapide o esecuzione interattiva, puoi passare i parametri become direttamente tramite la riga di comando:

• --become o -b: Attiva become.
• --become-method <METODO>: Specifica il metodo become (ad esempio, sudo).
• --become-user <UTENTE>: Specifica l'utente di destinazione (ad esempio, root).
• --ask-become-pass o -K: Richiede la password become durante l'esecuzione. Questo è utile per i test, ma generalmente non per l'automazione.

Esempio:

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

Garantire i diritti sudo per l'utente become

Configurare correttamente become in Ansible è solo metà della battaglia. L'utente con cui Ansible si connette (l'ansible_user) deve avere i privilegi sudo necessari sull'host di destinazione per diventare l'become_user. Questo viene configurato sull'host di destinazione all'interno del file /etc/sudoers o di un file sotto /etc/sudoers.d/.

Configurazione di sudoers

Il file sudoers definisce chi può eseguire quali comandi, e come chi. Una voce comune per consentire a un utente di connessione Ansible (devops_user in questo esempio) di eseguire qualsiasi comando come qualsiasi utente senza richiesta di password è:

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

Spiegazione:

• devops_user: Il nome utente con cui Ansible si connette (ansible_user).
• ALL: Questo utente può eseguire comandi da qualsiasi terminale.
• (ALL): Questo utente può eseguire comandi come qualsiasi utente.
• NOPASSWD:: Specifica che non è richiesta alcuna password per le operazioni sudo.
• ALL: Questo utente può eseguire tutti i comandi.

Attenzione: Concedere NOPASSWD: ALL conferisce all'ansible_user accesso root illimitato senza password, il che può rappresentare un rischio significativo per la sicurezza. Utilizza questa opzione solo se veramente necessario e assicurati che le credenziali del tuo ansible_user siano altamente sicure. Per una sicurezza più rigorosa, puoi specificare comandi esatti o set di comandi che l'utente è autorizzato a eseguire.

Verifica dell'accesso sudo

Prima di eseguire il tuo playbook, puoi verificare manualmente se il tuo ansible_user ha accesso sudo su un host di destinazione. Accedi all'host tramite SSH come ansible_user ed esegui:

# Verifica se puoi eseguire sudo come root senza password
sudo -n whoami

# Se è richiesta una password, ti verrà richiesto. Prova con un comando semplice:
sudo whoami

# Elenca i privilegi sudo per l'utente corrente:
sudo -l

# Elenca i privilegi sudo per un utente specifico (ad esempio, devops_user):
sudo -l -U devops_user

Se sudo -n whoami restituisce root senza richiesta di password, la tua configurazione NOPASSWD è probabilmente corretta. Se richiede una password, la tua voce sudoers potrebbe mancare di NOPASSWD o essere configurata in modo errato.

Diagnosi degli errori di escalation dei privilegi

Ansible fornisce tipicamente messaggi di errore informativi, ma i problemi relativi ai privilegi possono a volte essere criptici. Ecco errori comuni e le loro soluzioni:

1. "permission denied" o