Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configura gMSA per pod e contenitori Windows

Cos'è un account gMSA

Windows-based applicazioni come le applicazioni.NET utilizzano spesso Active Directory come provider di identità, fornendo l' authorization/authentication utilizzo del protocollo NTLM o Kerberos.

Un server applicativo per lo scambio di ticket Kerberos con Active Directory richiede l'aggiunta a un dominio. I contenitori Windows non supportano i join di dominio e non avrebbero molto senso in quanto i contenitori sono risorse temporanee, che rappresentano un onere per il pool RID di Active Directory.

Tuttavia, gli amministratori possono sfruttare gli account Active Directory di gMSA per negoziare un'autenticazione Windows per risorse come contenitori Windows, NLB e server farm.

Caso d'uso di Windows Container e gMSA

Le applicazioni che sfruttano l'autenticazione Windows e vengono eseguite come contenitori Windows traggono vantaggio da gMSA perché il nodo Windows viene utilizzato per scambiare il ticket Kerberos per conto del contenitore. Sono disponibili due opzioni per configurare il nodo di lavoro Windows per supportare l'integrazione gMSA:

1 - Nodi di lavoro Windows Domain-joined

In questa configurazione, il nodo di lavoro Windows è aggiunto al dominio Active Directory e l'account AD Computer dei nodi di lavoro Windows viene utilizzato per autenticarsi con Active Directory e recuperare l'identità gMSA da utilizzare con il pod.

Nell'approccio unito al dominio, puoi gestire e rafforzare facilmente i tuoi nodi di lavoro Windows utilizzando i GPO di Active Directory esistenti; tuttavia, genera un sovraccarico operativo aggiuntivo e ritardi durante l'unione del nodo di lavoro Windows nel cluster Kubernetes, poiché richiede riavvii aggiuntivi durante l'avvio del nodo e la pulizia del garage di Active Directory dopo che il cluster Kubernetes ha terminato i nodi.

Nel seguente post del blog, troverai una dettagliata procedura dettagliata su come implementare l'approccio del nodo di lavoro di Domain-joined Windows:

Autenticazione di Windows su pod Windows di Amazon EKS

2 - Nodi di lavoro Windows senza dominio

In questa configurazione, il nodo di lavoro Windows non viene aggiunto al dominio Active Directory e viene utilizzata un'identità «portatile» (user/password) per autenticarsi con Active Directory e recuperare l'identità gMSA da utilizzare con il pod.

L'identità portabile è un utente di Active Directory; l'identità (user/password) è archiviata su AWS Secrets Manager o AWS System Manager Parameter Store e un AWS-developed plug-in chiamato ccg_plugin verrà utilizzato per recuperare questa identità da AWS Secrets Manager o AWS System Manager Parameter Store e passarla a containerd per recuperare l'identità gMSA e renderla disponibile per il pod.

In questo approccio senza dominio, è possibile trarre vantaggio dall'assenza di alcuna interazione con Active Directory durante l'avvio del nodo di lavoro di Windows quando si utilizza gMSA e dalla riduzione del sovraccarico operativo per gli amministratori di Active Directory.

Nel seguente post del blog, troverai una dettagliata procedura dettagliata su come implementare l'approccio del nodo di lavoro Windows senza dominio:

Autenticazione Windows senza dominio per i pod Windows Amazon EKS

Nota importante

Nonostante il pod sia in grado di utilizzare un account gMSA, è necessario configurare anche l'applicazione o il servizio di conseguenza per supportare l'autenticazione di Windows, ad esempio, per configurare Microsoft IIS per supportare l'autenticazione di Windows, è necessario prepararlo tramite dockerfile:

RUN Install-WindowsFeature -Name Web-Windows-Auth -IncludeAllSubFeature
RUN Import-Module WebAdministration; Set-ItemProperty 'IIS:\AppPools\SiteName' -name processModel.identityType -value 2
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/anonymousAuthentication' -Name Enabled -Value False -PSPath 'IIS:\' -Location 'SiteName'
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name Enabled -Value True -PSPath 'IIS:\' -Location 'SiteName'