Modifica il file sudoers con un modello di playbook sensibile

Sto cercando di creare un file sudoers con un modello ansible. Il file sudoers dovrebbe apparire come di seguito:

Cmnd_Alias LS = /bin/ls
Cmnd_Alias LESS = /usr/bin/less
Cmnd_Alias DU = /usr/bin/du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

Quello che ho gestito finora è di seguito:

Cmnd_Alias LS = ls
Cmnd_Alias LESS = less
Cmnd_Alias DU = du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

Il modello è simile al seguente:

{% for item in commands %}
Cmnd_Alias {{ item|upper }} = {{ item }}
{% endfor %}

%{{ group }} ALL=(ALL) NOPASSWD: {% for item in commands %}
{{ item|upper}}{% if not loop.last %}, {% endif %}
{% endfor %}

Vars

commands:
  - ls
  - less
  - du

Per quanto ne so, il modulo modello ansible non ha nulla che eseguirà il comando nel server remoto e stamperà l'output, altrimenti stavo pensando di cambiare il file modello per apparire come di seguito:

{% for item in commands %}
Cmnd_Alias {{ item|upper }} = `which {{ item }}`
{% endfor %}

%{{ group }} ALL=(ALL) NOPASSWD: {% for item in commands %}
{{ item|upper}}{% if not loop.last %}, {% endif %}    
{% endfor %}

e l'output sarà come quello che volevo.

C'è qualche altro metodo che può renderlo semplice?

A proposito, ho già controllato questo post

TL; DR: KISS. Non usare di meno.

Le persone spesso commettono un errore con ansible cercando di fare cose variabili che non devono essere. A meno che non ci siano più posizioni in cui si definisce l'elenco dei comandi a cui può accedere il supporto, è perfettamente accettabile inserirli nel file di creazione del modello:

templates / etc / sudoers.d / Support1

Cmnd_Alias LS = /bin/ls
Cmnd_Alias LESS = /bin/cat
Cmnd_Alias DU = /usr/bin/du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

o anche esplicitamente poiché non riutilizzi Cmnd_Alias ​​da nessuna parte

%support1 ALL=(ALL) NOPASSWD: /bin/ls
%support1 ALL=(ALL) NOPASSWD: /bin/cat
%support1 ALL=(ALL) NOPASSWD: /usr/bin/du

E aggiungi alcune attività come:

- name: add templates
  template:
    src: {{ item }}
    dest: /{{ item }}
    owner: root
    group: root
    mode: 0640
  with_items:
    - etc/sudoers.d/support1

Utilizzeresti solo i modelli anziché i file perché in seguito potrebbero esserci delle variabili da aggiungere a tutti o il nome del gruppo potrebbe provenire da una variabile se ottieni un altro ruolo che crea i gruppi.

Se devi usare la variabile, la cosa che puoi fare è usare un elenco di hash come questo:

sudoers.support1.commands:
- { alias: "LS", path: "/bin/ls" }
- { alias: "DU", path: "/usr/bin/du" }

Quindi nel modello:

{% for item in sudoers.{{ group }}.commands %}
Cmnd_Alias {{ item.alias }} = {{ item.path }}
{% endfor %}
%{{ group }} ALL=(ALL) NOPASSWD: {{ sudoers.{{ group }}.commands | map(attribute='alias') | join(', ') }}

Non è sicuro usare / usr / bin / less

In tutto ciò non hai notato cose molto importanti e questo è l'uso di meno come visualizzatore. Purtroppo è un buco nella sicurezza. Puoi digitare '! Bash' per invocare bash. E premendo 'v' si entra nell'editor in base alle variabili VISUAL, EDITOR o LESSEDIT. Quindi puoi dare loro '/ bin / cat' e possono sempre convogliare il contenuto in meno se stessi. Nota che questa è ancora una falla di sicurezza poiché alcuni file in unix sono ad esempio intenzionalmente limitati:

/etc/shadow
/etc/sudoers
/etc/ssh/ssh_host_rsa_key
$HOME/.ssh/id_rsa

in primo luogo

dovresti fare riferimento alla gestione degli spazi / newline di Jinja. il tuo modello attuale creerebbe nuove linee, e penso che questo confonderà sudoe fallirà la convalida della sintassi (IIRC, la sintassi giusta è quella di aggiungere -tipo: -%}nel ciclo for, ma dovresti "giocare" e vedere cosa succede). Per eseguire il rendering di un modello è possibile farlo sulla propria stazione di lavoro, senza eseguirlo sul computer di destinazione effettivo.

Inoltre, penso che la creazione del modello con 1 comando nella riga di istruzioni sia più leggibile:

{% for command in commands %}
%{{group}} ALL=(ALL) NOPASSWD: {{command}}
{% endfor %}

in secondo luogo

Non consiglio di modificare i file globali esistenti con ansible. Invece crea il tuo modello personalizzato sotto /etc/sudoers.d/(come hai già detto che hai visto).

Questo è il modo giusto di farlo, perché:

• il sistema avrà tutti i valori predefiniti così come sono.
• il tuo modello sarà molto più breve.
• se si commettono errori, si sarebbe sicuri dove cercare - nel modello.

In terzo luogo

Penso che eseguire whichall'interno sudoerssia un'idea originale, ma non dovrebbe funzionare.