Implementare carichi di lavoro di Windows in contenitori
Contoso si basa su Active Directory Domain Services come provider di identità per carichi di lavoro basati su Windows e Linux, con Kerberos come protocollo di autenticazione primario. Il team di Sicurezza delle informazioni ha chiesto di esaminare le opzioni per l'integrazione di carichi di lavoro in contenitori ospitati da AKS in Azure Stack HCI con l'ambiente Active Directory Domain Services di Contoso. Considerando che si prevede di distribuire nodi e contenitori basati su Windows nei cluster Kubernetes, si vuole determinare in quale misura tale integrazione è possibile.
Integrare i contenitori di Windows in AKS in Azure Stack HCI con Active Directory Domain Services
In alcuni scenari le applicazioni basate su Windows in contenitori in esecuzione nei pod Kubernetes potrebbero richiedere l'accesso alle risorse protette da Active Directory Domain Services. Tale funzionalità richiede l'uso di un'identità basata su dominio di Active Directory Domain Services per completare correttamente le attività di autenticazione e autorizzazione. Per implementare questa identità, è possibile usare account del servizio gestito del gruppo (gMSA).
Rispetto al metodo tradizionale per la gestione delle identità per i servizi e le applicazioni Windows che devono essere in grado di eseguire l'autenticazione autonomamente, gMSA offre diversi vantaggi, tra cui le modifiche automatiche delle password, la configurazione e la manutenzione semplificate e il supporto per la gestione delegata.
Per consentire ai pod di usare gMSA per l'autenticazione, aggiungere tutti i nodi di lavoro Kubernetes basati su Windows Server che ospiteranno i pod in un dominio Active Directory Domain Services. Eseguire l'aggiunta al dominio connettendosi a ogni nodo tramite Secure Shell (SSH) e quindi eseguendo l'utilità della riga di comando netdom.exe con l'opzione join.
Il resto del processo è lo stesso di qualsiasi cluster Kubernetes che include nodi di lavoro di Windows Server e prevede i passaggi di alto livello seguenti:
- Provisioning di un gMSA in Active Directory Domain Services e assegnazione ai nodi di Windows Server.
- Definizione di un tipo di risorsa Kubernetes personalizzato che rappresenta l'istanza gMSA (GMSACredentialSpec) di Active Directory Domain Services.
- Configurazione di un meccanismo basato su webhook che popola e convalida automaticamente i riferimenti GMSACredentialSpec per pod e contenitori.
- Creazione di una risorsa personalizzata basata sul tipo di risorsa GMSACredentialSpec.
- Definizione di un ruolo del cluster per abilitare il controllo degli accessi in base al ruolo per la risorsa GMSACredentialSpec.
- Assegnazione del ruolo a gMSA di Active Directory Domain Services per autorizzare l'utilizzo della risorsa GMSACredentialSpec corrispondente.
- Inclusione di un riferimento alla risorsa GMSACredentialSpec nella definizione dei pod che la useranno per l'autenticazione di Active Directory Domain Services.
Nota
Per abilitare il supporto di gMSA, il nome del cluster Kubernetes non può superare i tre caratteri. Questo vincolo deriva dal limite di 15 caratteri di un nome computer aggiunto a un dominio.