In questo articolo, ci concentreremo su due importanti concetti di Ansible. Il primo concetto sarà come funziona l'autenticazione basata su chiave SSH e basata su password in Ansible. Il secondo concetto è come elevare il privilegio quando si lavora con comandi e playbook ad hoc.
Ho una configurazione di laboratorio a tre nodi che esegue macchine Ubuntu 20.04 LTS che utilizzano VirtualBox e Vagrant. C'è un articolo dettagliato sulla configurazione del laboratorio che puoi leggere dal link sottostante.
- Configurazione automatizzata di Ansible Lab con Vagrant e Virtualbox in Linux
Autenticazione basata su chiave in Ansible
La prima cosa che devi capire quando impari ansible è come sta avvenendo la comunicazione tra il controller e i nodi gestiti. Ansible utilizza il protocollo SSH per connettersi ai nodi gestiti ed eseguire l'attività.
Ogni volta che esegui un playbook o comandi ad hoc, devi fornire la password SSH per poter autenticare i nodi gestiti tramite SSH.
Per eliminarlo, si consiglia di creare una coppia di chiavi SSH e condividere la chiave pubblica con tutti i nodi in modo che ansible possa comunicare utilizzando la coppia di chiavi.
Ho creato due coppie di chiavi denominate first_key e seconda_chiave utilizzando lo script seguente per la dimostrazione.
Crea un file di testo chiamato create_keypair.sh con i seguenti contenuti.
#!/usr/bin/env bash
# THIS SCRIPT WILL CREATE SSH KEY PAIR AND DISTRIBUTE ACROSS ALL NODES
read -p "Enter the name for the key : " KEY_NAME
ssh-keygen -b 2048 -t rsa -f /home/vagrant/.ssh/${KEY_NAME} -q -N ""
# LOOPING THROUGH AND DISTRIBUTING THE KEY
for val in controller managed1 managed2; do
echo "-------------------- COPYING KEY TO ${val^^} NODE ------------------------------"
sshpass -p 'vagrant' ssh-copy-id -f -i /home/vagrant/.ssh/${KEY_NAME}.pub -o "StrictHostKeyChecking=no" [email protected]$val
done Concedi il permesso di esecuzione allo script ed eseguilo.
$ chmod +x path/to/create_keypair.sh
$ ./create_keypair.sh
Ho creato questo script per la configurazione del mio laboratorio. Puoi modificare la sezione del ciclo for e aggiungere i nomi dei nodi gestiti di conseguenza.
$ tree .ssh/
.ssh/
├── authorized_keys
├── first_key
├── first_key.pub
├── known_hosts
├── second_key
└── second_key.pub
Quando disponi di chiavi create con nomi diversi dal nome predefinito (id_rsa), ssh proverà a trovare i nomi delle chiavi predefiniti e, se non viene trovato, richiederà l'autenticazione basata su password.
debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/vagrant/.ssh/id_rsa debug1: Trying private key: /home/vagrant/.ssh/id_dsa debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa_sk debug1: Trying private key: /home/vagrant/.ssh/id_ed25519 debug1: Trying private key: /home/vagrant/.ssh/id_ed25519_sk debug1: Trying private key: /home/vagrant/.ssh/id_xmss debug1: Next authentication method: password [email protected]'s password:
In questo caso, devi menzionare esplicitamente il file della chiave privata usando -i bandiera.
$ ssh -v -i /home/vagrant/.ssh/first_key [email protected]
Quando esegui un comando o un playbook ad hoc, puoi utilizzare il --key-file o --private-key contrassegnare e passare il file della chiave privata come argomento. Nell'esempio seguente, puoi vedere che ho usato entrambe le chiavi (first_key e second_key) per comunicare correttamente con i nodi gestiti.
# USING --key-file FLAG
$ ansible managed1 -m ping --key-file /home/vagrant/.ssh/second_key
managed1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
} # USING --private-key FLAG
$ ansible managed1 -m ping --private-key /home/vagrant/.ssh/first_key
managed1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
Puoi anche aggiungere il parametro "private_key_file " nel ansible.cfg file di configurazione che verrà applicato ai comandi ad hoc e a tutte le attività del playbook.
$ vim ansible.cfg
Aggiungi la seguente riga:
Private_key_file = /home/vagrant/.ssh/first_key
Sostituisci /home/vagrant/.ssh/first_key con il tuo.
Puoi anche aggiungere "ansible_ssh_private_key" parametro nel tuo file di inventario che avrà maggiore precedenza su ansible.cfg file. Di seguito è riportato come è ora impostato il mio inventario. Nodo gestito1 utilizzerà "first_key" e gestito2 utilizzerà "second_key" .
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key [ubuntu2] managed2 ansible_ssh_private_key_file=/home/vagrant/.ssh/second_key
Ora, se esegui di nuovo il comando adhoc o il playbook, puoi vedere che entrambe le chiavi si autenticheranno correttamente. Puoi aumentare la verbosità per verificare se vengono utilizzate le chiavi appropriate secondo il nostro input.
$ ansible -vvv all -m ping
Ora dovresti avere una buona comprensione di come funziona l'autenticazione basata su chiave in ansible. È importante comprendere la precedenza quando si aggiunge il parametro in file diversi. L'opzione della riga di comando ha la precedenza, seguita dal file di inventario e da ansible.cfg file di configurazione.
Autenticazione basata su password SSH in Ansible
Quando esegui qualsiasi attività, ansible utilizzerà l'utente corrente nel nodo controller per comunicare con i nodi gestiti tramite SSH. Puoi usare il modulo shell ed eseguire il file "whoami " comando per verificare il nome utente nei nodi gestiti. Nel mio caso, il nome utente è "vagabondo" . L'utente vagabondo si sta autenticando utilizzando le chiavi che ho impostato nella sezione precedente.
$ whoami
vagrant
$ ansible all -m shell -a "whoami" managed2 | CHANGED | rc=0 >> vagrant managed1 | CHANGED | rc=0 >> vagrant
Se desideri connetterti ai nodi gestiti come un utente diverso puoi utilizzare --u o --user flag e passa username come argomento. Se vedi l'immagine qui sotto, provo a utilizzare l'utente "karthick" che non ha una configurazione della chiave SSH e nessuna chiave distribuita ai nodi gestiti, quindi la connettività non riesce.
$ ansible all -m shell -a "whoami" -u karthick
$ ansible all -m shell -a "whoami" --user karthick
Per utilizzare l'autenticazione basata su password, puoi utilizzare il -k o --ask-pass bandiera. Ti verrà chiesto di inserire la password SSH per l'utente (karthick). Assicurati che la password sia la stessa in tutti i nodi per l'utente.
$ ansible all -m shell -a "whoami" -u karthick -k
$ ansible all -m shell -a "whoami" -u karthick --ask-pass
Puoi anche memorizzare la password in un file e passare il nome del file come argomento a --connection-password-file o --conn-pass-file bandiera. Questo non è un modo consigliato poiché stai memorizzando la password in un file di testo normale. Puoi utilizzare ansible vault per crittografare il file della password, ma questo è un argomento separato di cui discutere.
$ ansible all -m shell -a "whoami" -u karthick --connection-password-file pass.txt
$ ansible all -m shell -a "whoami" -u karthick --conn-pass-file pass.txt
Puoi anche passare il nome utente e la password come parametri nel file di inventario. Anche in questo caso non è il modo migliore per memorizzare la password. Di seguito è riportato come è ora impostato il mio file di inventario.
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key ansible_user=vagrant [ubuntu2] managed2 ansible_user=karthick ansible_ssh_pass=password
$ ansible all -m shell -a "whoami" -u karthick managed1 | CHANGED | rc=0 >> vagrant managed2 | CHANGED | rc=0 >> karthick
Avviso: Potrei eseguire gli esempi utilizzando comandi ad hoc, ma gli stessi flag sono applicabili anche al playbook.
Escalation dei privilegi in Ansible
Ci sono volte in cui l'attività richiede privilegi elevati (root) per essere eseguita correttamente. Ad esempio, la gestione dei pacchetti. Puoi installare, rimuovere o aggiornare i pacchetti solo come root utente o con sudo privilegio.
Quando esegui il flag della guida insieme a ansible o ansible-playbook, troverai una sezione di escalation dei privilegi come mostrato nell'immagine.
$ ansible --help
$ ansible-playbook --help
Quando vuoi eseguire qualsiasi attività con root privilegio, dovresti usare -b o --become bandiera.
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -b
managed1 | CHANGED => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": true,
"name": "sshd",
"state": "started",
Per impostazione predefinita, sudo verrà utilizzato come metodo di escalation dei privilegi. Puoi cambiare il metodo impostando il --become-method bandiera. Puoi ottenere l'elenco dei metodi supportati eseguendo il comando seguente.
$ ansible-doc -t become -l ansible.netcommon.enable Switch to elevated permissions on a network device community.general.doas Do As user community.general.dzdo Centrify's Direct Authorize community.general.ksu Kerberos substitute user community.general.machinectl Systemd's machinectl privilege escalation community.general.pbrun PowerBroker run community.general.pfexec profile based execution community.general.pmrun Privilege Manager run community.general.sesu CA Privileged Access Manager community.general.sudosu Run tasks using sudo su - runas Run As user su Substitute User sudo Substitute User DO
Puoi dare o meno un sudo password per i nodi gestiti in base alla configurazione dell'utente. Nel mio caso, ho impostato l'utente vagabondo per eseguire sudo senza richiedere le password.
Se il tuo sudo utente richiede una password per funzionare, quindi dovresti usare il -K o --ask-become-pass flag che richiederà il sudo parola d'ordine.
Come puoi vedere dall'errore seguente, quando provo a eseguire senza fornire un sudo password per l'utente "karthick", mi genera un errore che dice "Sudo password mancante" .
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b
SSH password:
managed1 | FAILED! => {
"msg": "Missing sudo password"
} $ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b -K
La password Sudo può essere archiviata in un file e passata come argomento al --become-password-file o --become-pass-file bandiera. Ansible Vault può essere utilizzato per crittografare questo file, ma non è una pratica consigliata.
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-password-file pass.txt $ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-pass-file pass.txt
Puoi anche includere il "diventa" direttiva nel playbook a livello di attività o di gioco.
L'immagine sotto rappresenta come il "diventa" la direttiva viene utilizzata a livello di gioco .
L'immagine sotto rappresenta come il "diventa" viene utilizzata a livello di attività .
Come puoi vedere dall'output, il ssh il servizio viene riavviato correttamente in gestito1 nodo.
$ ansible-playbook restart_service.yml PLAY [Restart SSHD service] *************************************************************************** TASK [Restart SSHD in managed1.anslab.com] ************************************************************ changed: [managed1] PLAY RECAP ******************************************************************************************** managed1 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
La direttiva "become" può anche essere impostata su ansible.cfg file di configurazione e il file di inventario. Ma si consiglia di impostare la direttiva nel playbook. Puoi ottenere i diversi parametri per ansible.cfg file dal link sottostante.
- Diventa direttiva
Se desideri eseguire l'attività come un utente diverso dopo la connessione ai nodi gestiti, devi utilizzare il --become-user bandiera. Per impostazione predefinita, è impostato su root utente.
Conclusione
In questo articolo, abbiamo visto come funziona l'autenticazione basata su chiave e password in Ansible e diversi flag supportati per l'autenticazione. Abbiamo anche visto come funziona l'escalation dei privilegi in Ansible.
Per approfondire, dovresti avere una buona conoscenza di come funziona il diverso metodo di escalation dei privilegi e in base alle tue esigenze impostare l'ambiente senza compromettere la sicurezza.
Leggi il prossimo:
- Iniziare con i comandi ad hoc Ansible