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
Aplicativos baseados em Windows, como aplicativos.NET, geralmente usam o Active Directory como provedor de identidade, fornecendo o uso do protocolo NTLM ou authorization/authentication 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 de 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 o Active Directory existente GPOs; 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á detalhes step-by-step sobre como implementar a abordagem de nó de trabalho do Windows associado ao domínio:
[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” (usuário/senha) é usada para se autenticar no Active Directory e recuperar a identidade gMSA a ser usada com o pod.
![\[gmsa sem domínio\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/windows/domainless_gmsa.png)
A identidade portátil é de um usuário do Active Directory; a identidade (usuário/senha) é armazenada no AWS Secrets Manager ou no AWS System Manager Parameter Store, e um plug-in desenvolvido pela AWS chamado ccg\$1plugin 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á detalhes step-by-step 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'
```