Utilizzo di Kerberos per Windows in Ansible Automation Platform 2

Kerberos è in genere il metodo di autenticazione preferito per la gestione dei server Windows in un ambiente di dominio. Da diversi anni, Red Hat Ansible Automation Platform consente ai clienti di utilizzare l'autenticazione Kerberos. Perché allora tornare sull'argomento? 

Rilasciato nel luglio 2021, Ansible Automation Platform 2 rappresentava all'epoca una riorganizzazione importante della piattaforma, che vedeva, tra i principali cambiamenti, l'introduzione di Automation Execution Environment , ovvero ambienti definiti, coerenti e portabili per l'esecuzione degli Ansible Playbook. Senza scendere troppo nel dettaglio, gli Automation Execution Environment prevedono un'immagine RHEL di base, Ansible Core e tutte le dipendenze necessarie a eseguire l'automazione Ansible, in genere Ansible Content Collections e librerie Python. 

Passare ai container significa a volte considerare che anche il localhost è un container. Un interessante articolo del blog spiega in dettaglio quando il localhost non è ciò che sembra in ambito di Automation Execution Environment.

Tenendo a mente questo aspetto, esamineremo un esempio guidato su come configurare l'autenticazione di Kerberos in Ansible Automation Platform 2, testare la configurazione e configurare Automation Controller per l'utilizzo di Kerberos.

Esempio di configurazione

Per poter utilizzare Kerberos con Ansible, è necessario un file di configurazione di Kerberos. Il contenuto del file di configurazione varia in base a diversi fattori: la configurazione DNS, il rilevamento del KDC e il numero di domini. In questo esempio, è presente un singolo dominio DEMOLAB.LOCAL che non è rilevabile dal server del controller di automazione.

Ecco la configurazione del client Kerberos di esempio. Un esempio simile è documentato nella guida dell'amministratore di Automation Controller.

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }

Dobbiamo quindi considerare gli Automation Execution Environment e tenere presente che il localhost non è quello che sembra. Quando Automation Controller esegue un Ansible Playbook, richiama un'immagine del container che non ha accesso al filesystem alla base del nodo del controller. Pertanto, è necessario verificare che l'ambiente di esecuzione abbia accesso alla configurazione del client Kerberos. Per farlo, sono disponibili due opzioni.

1. Eseguire il mapping della configurazione del client Kerberos all'ambiente di esecuzione attivo da Automation Controller.
2. Personalizzare e creare il proprio ambiente di esecuzione utilizzando Ansible Builder e aggiungere krb5.conf all'immagine.

In questo esempio, poiché non è necessario apportare altre modifiche, eseguiamo il mapping della configurazione del client Kerberos all'ambiente di esecuzione attivo. 

Per farlo, scriviamo la configurazione nella directory di configurazione del client Kerberos sul server di Automation Controller chiamato /etc/krb5.conf.d/DEMOLAB.LOCAL.conf

 # cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf 

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }  

Test dalla riga di comando

A questo punto possiamo verificare la configurazione dalla riga di comando. Innanzitutto, confermiamo gli ambienti di esecuzione disponibili per i test. Sul server di Automation Controller passiamo all'utente awx per visualizzare le immagini disponibili dell'ambiente di esecuzione. Nell'esempio è disponibile l'ambiente di esecuzione ee-supported-rhel8, ovvero l'immagine con cui eseguire il test.

$ su - awx 
$ podman images 
REPOSITORY                                                         TAG     IMAGE ID   CREATED   SIZE 
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8  latest   024856bccc5f  4 weeks ago  1.66 GB

Per eseguire il test con un'altra immagine, utilizziamo il comando "podman pull" per copiare l'immagine pertinente da un registro dei container.

A questo punto, cerchiamo di capire se è possibile eseguire il mapping della directory di configurazione all'ambiente di esecuzione, e quindi autenticare e ottenere un ticket Kerberos. Il comando Podman seguente avvia il container dell'ambiente di esecuzione ed esegue il mapping di /etc/krb5.conf.d/ al container in esecuzione. Viene inoltre fornita una shell interattiva all'interno del container per eseguire il test di kinit. Infine, Kerberos conserva le credenziali Kerberos valide in una cache delle credenziali. Come già detto prima, qui localhost non è ciò che sembra, quindi non abbiamo accesso al filesystem e alla cache di Kerberos. Creiamo una cache delle credenziali Kerberos temporanea che ci permetterà di testare la configurazione impostando la variabile KRB5CCNAME. Il plugin di connessione winrm utilizza un meccanismo simile. 

$ podman run --rm  -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash 

bash-4.4# export KRB5CCNAME=`mktemp` 
bash-4.4# echo $KRB5CCNAME 
/tmp/tmp.ZzBXbtGiV1 
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL 
Password for svc-ansible@DEMOLAB.LOCAL: 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
04/04/23 14:01:37  04/05/23 00:01:37  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 04/11/23 14:01:33

Come prova aggiuntiva, possiamo verificare se il ticket funziona per l'autenticazione su un server specifico. Dopo aver eseguito correttamente kinit nell'ambiente di esecuzione, possiamo utilizzare kvno per eseguire l'autenticazione con un host di destinazione. Nel nostro esempio, verifichiamo di poter utilizzare il ticket per eseguire l'autenticazione con windows2.demolab.local.

bash-4.4# kvno http/windows2.demolab.local 
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
05/10/23 15:26:35  05/11/23 01:26:35  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:33 
05/10/23 15:26:49  05/11/23 01:26:35  http/windows2.demolab.local@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:3

Il test sembra riuscito! Possiamo quindi trasferire la configurazione in Automation Controller. 

Configurazione di Automation Controller

In Automation Controller dobbiamo aggiungere una credenziale Machine per il nostro account Windows, che deve essere il nome utente UPN nel formato 'nomeutente@DOMAIN.COM'. Per aggiungere una credenziale in Automation Controller, passa a Credentials nel menu a sinistra, premi Add e seleziona il tipo di credenziale Machine. Quindi inserisci l'utente e la password del dominio come nell'esempio:

A questo punto possiamo eseguire il mapping della configurazione del client Kerberos nell'ambiente di esecuzione. Un amministratore deve configurare Settings -> Job Settings  e modificare il percorso da esporre ai processi isolati aggiungendo la directory Kerberos. È lo stesso formato utilizzato per i test dalla riga di comando. La nuova configurazione dovrebbe essere simile alla seguente:

Vediamo se funziona. Possiamo utilizzare un semplice playbook "ping" per convalidare la configurazione, e anche aumentare gli accessi per includere i messaggi di connessione di WinRM. Modifica il modello di processo e imposta il livello di dettaglio sul livello 5.

All'avvio del modello di processo, vengono visualizzati i messaggi di connessione dettagliati.

Come si vede, è stata creata la cache delle credenziali Kerberos temporanea, l'account è in grado di eseguire l'autenticazione e abbiamo ottenuto un ticket. L'esecuzione del playbook dovrebbe completarsi correttamente.

Risoluzione dei problemi

Durante la configurazione di Kerberos in un ambiente di esecuzione, potrebbero verificarsi alcuni errori. Di seguito sono riportati alcuni esempi di messaggi di errore e di possibili soluzioni.

• Impossibile leggere la directory del profilo inclusa durante l'inizializzazione della libreria Kerberos 5 - Il messaggio potrebbe indicare la presenza di un file di configurazione nella directory /etc/krb5.conf.d che sta tentando di includere directory aggiuntive alle quali l'ambiente di esecuzione non può accedere. Controlla tutti i file di configurazione in /etc/krb5.conf.d nei quali potrebbe essere presente un'opzione includesir.
• UID non valido nel nome del keyring permanente durante la ricezione della ccache predefinita - Ricorda di impostare una directory cache delle credenziali temporanea come descritto sopra.
• Impossibile trovare il KDC per il dominio "<DOMAIN>" durante il recupero delle credenziali iniziali - Questo errore può avere diverse cause. Verifica che la configurazione di Kerberos sia corretta e che nella configurazione sia elencato un KDC valido. Se ti affidi al DNS per la ricerca dei KDC, verifica che dns_lookup_kdc sia impostato su true. 
• Impossibile trovare il server nel database Kerberos: spesso l'errore è dovuto a problematiche DNS o a un inventario Ansible configurato in modo errato. Verifica che il nome dell'host nell'inventario corrisponda al nome del server nel DNS. Verifica inoltre che Ansible tenti di connettersi all'host con l'FQDN utilizzando i log di debug di WinRM. Di seguito è riportato un esempio in cui la variabile ansible_host è impostata per un server Windows e si tenta di connettersi all'IP anziché al nome host.

Passaggi successivi

Mi auguro che questo esempio sia stato utile per comprendere alcune delle novità inserite in Ansible Automation Platform 2 e per capire come iniziare a utilizzare l'autenticazione Kerberos per la gestione dei server Windows. Poiché Windows riveste molta importanza in Ansible, il numero di risorse disponibili per facilitare il tuo percorso è in continuo aumento.

• Ansible per Windows: scopri come utilizzare Ansible per gestire l'infrastruttura Windows e gli scenari di utilizzo più comuni.
• Sottoscrizione di prova. Tutto pronto per iniziare? Avvia una sottoscrizione di prova per l'accesso illimitato a tutti i componenti di Ansible Automation Platform.