As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configurar o gMSA para pods e contêineres do Windows

O que é uma conta gMSA

Windows-based aplicativos como aplicativos.NET geralmente usam o Active Directory como um provedor de identidade, fornecendo o authorization/authentication uso do protocolo NTLM ou Kerberos.

Um servidor de aplicativos para trocar tíquetes Kerberos com o Active Directory precisa estar associado ao domínio. Os contêineres do Windows não oferecem suporte a uniões de domínios e não fariam muito sentido, pois os contêineres são recursos efêmeros, criando uma sobrecarga no pool RID do Active Directory.

No entanto, os administradores podem aproveitar as contas gMSA do Active Directory para negociar uma autenticação do Windows para recursos como contêineres do Windows, NLB e fazendas de servidores.

Contêiner do Windows e caso de uso do gMSA

Os aplicativos que utilizam a autenticação do Windows e são executados como contêineres do Windows se beneficiam do gMSA porque o Windows Node é usado para trocar o tíquete Kerberos em nome do contêiner. Há duas opções disponíveis para configurar o nó de trabalho do Windows para oferecer suporte à integração do gMSA:

1 - Nodos de trabalho Domain-joined do Windows

Nessa configuração, o nó de trabalho do Windows é unido ao domínio do Active Directory, e a conta AD Computer dos nós de trabalho do Windows é usada para fazer a autenticação no Active Directory e recuperar a identidade gMSA a ser usada com o pod.

Na abordagem de união de domínios, você pode gerenciar e fortalecer facilmente seus nós de trabalho do Windows usando GPOs existentes do Active Directory; no entanto, isso gera sobrecarga operacional adicional e atrasos durante a adesão dos nós de trabalho do Windows ao cluster Kubernetes, pois exige reinicializações adicionais durante a inicialização do nó e a limpeza da garagem do Active Directory após o cluster Kubernetes encerrar os nós.

Na postagem do blog a seguir, você encontrará um passo a passo detalhado sobre como implementar a abordagem do nó de trabalho do Domain-joined Windows:

Autenticação do Windows em pods Windows do Amazon EKS

2 - Nodes de trabalho do Windows sem domínio

Nessa configuração, o nó de trabalho do Windows não está associado ao domínio do Active Directory e uma identidade “portátil” (user/password) é usada para autenticar no Active Directory e recuperar a identidade gMSA a ser usada com o pod.

A identidade portátil é de um usuário do Active Directory; a identidade (user/password) é armazenada no AWS Secrets Manager ou no AWS System Manager Parameter Store, e um AWS-developed plug-in chamado ccg_plugin será usado para recuperar essa identidade do AWS Secrets Manager ou do AWS System Manager Parameter Store e passá-la ao containerd para recuperar a identidade gMSA e disponibilizá-la para o pod.

Nessa abordagem sem domínio, você pode se beneficiar de não ter nenhuma interação com o Active Directory durante a inicialização do nó de trabalho do Windows ao usar o gMSA e reduzir a sobrecarga operacional dos administradores do Active Directory.

Na postagem do blog a seguir, você encontrará um passo a passo detalhado sobre como implementar a abordagem do nó de trabalho Windows sem domínio:

Autenticação do Windows sem domínio para pods Windows do Amazon EKS

Observação importante

Apesar de o pod poder usar uma conta gMSA, também é necessário configurar o aplicativo ou serviço adequadamente para suportar a autenticação do Windows. Por exemplo, para configurar o Microsoft IIS para oferecer suporte à autenticação do Windows, você deve prepará-lo via 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'