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 provedor de identidade, fornecendo authorization/authentication usando o protocolo NTLM ou Kerberos.
Um servidor de aplicativos para trocar tíquetes Kerberos com o Active Directory precisa ser associado a um domínio. Os contêineres do Windows não oferecem suporte a uniões de domínio e não fariam muito sentido, pois os contêineres são recursos efêmeros, sobrecarregando o pool RID do Active Directory.
No entanto, os administradores podem aproveitar as contas [gMSA do Active Directory](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) para negociar uma autenticação do Windows para recursos como contêineres do Windows, NLB e farms de servidores.
## Caso de uso do contêiner Windows e 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 ticket 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:
Nessa configuração, o nó de trabalho do Windows é associado ao domínio do Active Directory, e a conta AD Computer dos nós de trabalho do Windows é usada para se autenticar no Active Directory e recuperar a identidade gMSA a ser usada com o pod.
Na abordagem unida por domínio, você pode gerenciar e fortalecer facilmente seus nós de trabalho do Windows usando os GPOs existentes do Active Directory; no entanto, isso gera sobrecarga operacional adicional e atrasos durante a união do nó de trabalho do Windows no cluster Kubernetes, pois requer 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 Domain-joined Windows Worker Node:
[Autenticação do Windows em pods Windows do Amazon EKS](https://aws.amazon.com/blogs/containers/windows-authentication-on-amazon-eks-windows-pods/)
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 se 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 para o 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 de nó de trabalho do Windows sem domínio:
[Autenticação do Windows sem domínio para pods Windows do Amazon EKS](https://aws.amazon.com/blogs/containers/domainless-windows-authentication-for-amazon-eks-windows-pods/)
Apesar de o pod poder usar uma conta gMSA, também é necessário configurar o aplicativo ou serviço adequadamente para oferecer suporte à 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'
```