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 ](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) 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:
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 ](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 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 ](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 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'
```