Criar gMSAs para contêineres do Windows
Aplica-se a: Windows Server 2025, Windows Server 2022, Windows Server 2019
As redes baseadas no Windows geralmente usam o Ative Directory (AD) para facilitar a autenticação e a autorização entre usuários, computadores e outros recursos de rede. Os desenvolvedores de aplicativos corporativos geralmente projetam seus aplicativos para serem integrados ao AD e executados em servidores associados ao domínio para aproveitar a Autenticação Integrada do Windows, que facilita o login automático e transparente dos usuários e outros serviços no aplicativo com suas identidades. Este artigo explica como começar a usar contas de serviço gerenciado de grupo do Ative Directory com contêineres do Windows.
Embora os contêineres do Windows não possam ser associados ao domínio, eles ainda podem usar identidades de domínio do Ative Directory para oferecer suporte a vários cenários de autenticação. Para conseguir isso, você pode configurar um contêiner do Windows para ser executado com um grupo de Conta de Serviço Gerenciado (gMSA), que é um tipo especial de conta de serviço introduzido no Windows Server 2012 e projetado para permitir que vários computadores compartilhem uma identidade sem precisar saber sua senha. Os contêineres do Windows não podem ser associados ao domínio, mas muitos aplicativos do Windows executados em contêineres do Windows ainda precisam da Autenticação do AD. Para usar a Autenticação do AD, você pode configurar um contêiner do Windows para ser executado com uma Conta de Serviço Gerenciado (gMSA) de grupo.
Quando o gMSA para contêineres do Windows foi inicialmente introduzido, ele exigia que o host do contêiner fosse associado ao domínio, o que criava muita sobrecarga para os usuários associarem manualmente nós de trabalho do Windows a um domínio. Essa limitação foi resolvida com o suporte ao gMSA para contêineres do Windows para hosts de contêiner não associados ao domínio. Continuaremos a oferecer suporte à funcionalidade gMSA original para usar um host de contêiner associado ao domínio.
As melhorias no gMSA ao usar um host de contêiner não associado ao domínio incluem:
- O requisito de unir manualmente nós de trabalho do Windows a um domínio é eliminado porque causava muita sobrecarga para os usuários. Para cenários de dimensionamento, o uso de um host de contêiner não associado ao domínio simplifica o processo.
- Em cenários de atualização contínua, os utilizadores já não precisam de reassociar o nó a um domínio.
- Gerir as contas das máquinas dos nós de trabalho para recuperar senhas de contas de serviço do gMSA é um processo mais fácil.
- Configurar o gMSA com o Kubernetes é um processo de ponta a ponta menos complicado.
Observação
Para saber como a comunidade Kubernetes suporta o uso do gMSA com contêineres do Windows, consulte configurando o gMSA.
Arquitetura e Melhorias do gMSA
Para resolver as limitações da implementação inicial do gMSA para contêineres do Windows, o novo suporte do gMSA para hosts de contêiner não associados ao domínio usa uma identidade de usuário portátil em vez de uma conta de computador host para recuperar credenciais do gMSA. Portanto, unir manualmente nós de trabalho do Windows a um domínio não é mais necessário, embora ainda seja suportado. A identidade/credenciais do usuário são armazenadas em um armazenamento secreto acessível ao host do contêiner (por exemplo, como um segredo do Kubernetes) onde os usuários autenticados podem recuperá-lo.
O suporte do gMSA para hosts de contêiner não associados ao domínio oferece a flexibilidade de criar contêineres com o gMSA sem unir o nó do host ao domínio. A partir do Windows Server 2019, há suporte para ccg.exe que permite um mecanismo de plug-in para recuperar credenciais gMSA do Ative Directory. Você pode usar essa identidade para iniciar o contêiner. Para obter mais informações sobre esse mecanismo de plug-in, consulte a interface ICcgDomainAuthCredentials.
Observação
No Serviço Kubernetes do Azure no Azure Stack HCI, você pode usar o plug-in para se comunicar do ccg.exe para o AD e, em seguida, recuperar as credenciais do gMSA. Para obter mais informações, consulte configurar a Conta de Serviço Gerenciado do grupo com o AKS no Azure Stack HCI.
Veja o diagrama abaixo para seguir as etapas do processo do Container Credential Guard:
Usando um arquivo CredSpec como entrada, o processo ccg.exe é iniciado no host do nó.
ccg.exe usa informações no arquivo CredSpec do para iniciar um plug-in e, em seguida, recuperar as credenciais da conta no armazenamento secreto associado ao plug-in.
ccg.exe usa as credenciais da conta recuperada para recuperar a senha gMSA do AD.
ccg.exe disponibiliza a senha gMSA para um contêiner que solicitou credenciais.
O contêiner autentica-se no controlador de domínio usando a senha gMSA para obter um bilhete Kerberos Ticket-Granting (TGT).
Os aplicativos executados como Serviço de Rede ou Sistema Local no contêiner agora podem autenticar e acessar recursos de domínio, como o gMSA.
Pré-requisitos
Para executar um contêiner do Windows com uma conta de serviço gerenciado de grupo, você precisará do seguinte:
- Um domínio do Ative Directory com pelo menos um controlador de domínio executando o Windows Server 2012 ou posterior. Não há requisitos de nível funcional de floresta ou domínio para usar gMSAs, mas as senhas gMSA só podem ser distribuídas por controladores de domínio que executam o Windows Server 2012 ou posterior. Para obter mais informações, consulte requisitos do Ative Directory para gMSAs.
- Permissão para criar uma conta gMSA. Para criar uma conta gMSA, é necessário ser Administrador de Domínio ou usar uma conta à qual tenha sido delegada a permissão Criar objetos msDS-GroupManagedServiceAccount.
- Acesso à Internet para baixar o módulo CredentialSpec PowerShell. Se você estiver trabalhando em um ambiente desconectado, poderá salvar o módulo em um computador com acesso à Internet e copiá-lo para sua máquina de desenvolvimento ou host de contêiner.
Preparação única do Ative Directory
Se você ainda não criou um gMSA em seu domínio, precisará gerar a chave raiz do Serviço de Distribuição de Chaves (KDS). O KDS é responsável por criar, rodar e liberar a senha gMSA para os hosts autorizados. Quando um host de contêiner precisar usar o gMSA para executar um contêiner, ele entrará em contato com o KDS para recuperar a senha atual.
Para verificar se a chave raiz do KDS já foi criada, execute o seguinte cmdlet do PowerShell como administrador de domínio em um controlador de domínio ou membro do domínio com as ferramentas do AD PowerShell instaladas:
Get-KdsRootKey
Se o comando retornar uma ID de chave, você estará pronto e poderá pular para a seção criar uma conta de serviço gerenciada de grupo. Caso contrário, continue a proceder à criação da chave raiz do KDS.
Importante
Você deve criar apenas uma chave raiz KDS por floresta. Se várias chaves raiz do KDS forem criadas, isso fará com que o gMSA comece a falhar depois que a senha do gMSA for alterada.
Em um ambiente de produção ou ambiente de teste com vários controladores de domínio, execute o cmdlet a seguir no PowerShell como Administrador de Domínio para criar a chave raiz do KDS.
# For production environments
Add-KdsRootKey -EffectiveImmediately
Embora o comando implique que a chave entrará em vigor imediatamente, você precisará aguardar 10 horas antes que a chave raiz do KDS seja replicada e esteja disponível para uso em todos os controladores de domínio.
Se você tiver apenas um controlador de domínio em seu domínio, poderá agilizar o processo definindo a chave para entrar em vigor há 10 horas.
Importante
Não use essa técnica em um ambiente de produção.
# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
Criar uma Conta de Serviço Gerenciado de grupo
Cada contêiner que usa a Autenticação Integrada do Windows precisa de pelo menos um gMSA. O gMSA principal é usado sempre que aplicativos executados como um Sistema ou um Serviço de Rede acessam recursos na rede. O nome do gMSA se tornará o nome do contêiner na rede, independentemente do nome do host atribuído ao contêiner. Os contêineres também podem ser configurados com gMSAs adicionais, caso você queira executar um serviço ou aplicativo no contêiner como uma identidade diferente da conta do computador do contêiner.
Ao criar um gMSA, você também cria uma identidade compartilhada que pode ser usada simultaneamente em várias máquinas diferentes. O acesso à senha gMSA é protegido por uma Lista de Controle de Acesso do Ative Directory. Recomendamos criar um grupo de segurança para cada conta gMSA e adicionar os hosts de contêiner relevantes ao grupo de segurança para limitar o acesso à senha.
Finalmente, como os contêineres não registram automaticamente nenhum SPN (Service Principal Names), você precisará criar manualmente pelo menos um SPN de host para sua conta gMSA.
Normalmente, o host ou SPN HTTP é registado usando o mesmo nome da conta gMSA, mas talvez seja necessário usar um nome de serviço diferente se os clientes acederem à aplicação em contentor por trás de um balanceador de carga ou um nome DNS diferente do nome gMSA.
Por exemplo, se a conta gMSA for chamada "WebApp01", mas seus usuários acessarem o site em mysite.contoso.com
, você deverá registrar um SPN http/mysite.contoso.com
na conta gMSA.
Alguns aplicativos podem exigir SPNs adicionais para seus protocolos exclusivos. Por exemplo, o SQL Server requer o SPN MSSQLSvc/hostname
.
A tabela a seguir lista os atributos necessários para criar um gMSA.
Propriedade gMSA | Valor necessário | Exemplo |
---|---|---|
Nome | Qualquer nome de conta válido. | WebApp01 |
DnsHostName | O nome de domínio anexado ao nome da conta. | WebApp01.contoso.com |
ServicePrincipalNames | Defina pelo menos o SPN do host, adicione outros protocolos conforme necessário. | 'host/WebApp01', 'host/WebApp01.contoso.com' |
PrincipaisAutorizadosARecuperarSenhaGerida | O grupo de segurança que contém seus hosts de contêiner. | WebApp01Hosts |
Depois de decidir o nome do gMSA, execute os cmdlets a seguir no PowerShell para criar o security group e o gMSA.
Dica
Você precisará usar uma conta que pertença ao grupo de segurança Administradores do Domínio ou à qual tenha sido delegada a permissão Criar objetos msDS-GroupManagedServiceAccount para executar os comandos a seguir. O cmdlet New-ADServiceAccount faz parte das Ferramentas de Administração de Servidor Remoto do conjunto AD PowerShell .
Recomendamos que você crie contas gMSA separadas para seus ambientes de desenvolvimento, teste e produção.
Caso de uso para criar uma conta gMSA para os hosts de contentores integrados no domínio
# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.
# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat
# Create the security group
New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName "WebApp01Hosts" -GroupScope DomainLocal
# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"
# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$", "ContainerHost02$", "ContainerHost03$"
Caso de uso para criar uma conta gMSA para hosts de contêiner não associados ao domínio
Ao usar o gMSA para contêineres com hosts que não ingressaram no domínio, em vez de adicionar hosts de contêiner ao grupo de segurança WebApp01Hosts
, crie e adicione uma conta de usuário padrão.
# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.
# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat
# Create the security group
New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName "WebApp01Accounts" -GroupScope DomainLocal
# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"
# Create the standard user account. This account information needs to be stored in a secret store and will be retrieved by the ccg.exe hosted plug-in to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with a unique username and password. We recommend using a random, long, machine-generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled 1
# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"
Prepare seu host de contêiner
Caso de uso para preparar o host do contentor para um contentor registado no domínio
Cada host de contêiner que executará um contêiner do Windows com um gMSA deve ser associado ao domínio e ter acesso para recuperar a senha do gMSA.
Junte o computador ao domínio do Ative Directory.
Certifique-se de que o seu anfitrião pertence ao grupo de segurança que controla o acesso à palavra-passe gMSA.
Reinicie o computador para obter sua nova associação de grupo.
Configure Docker Desktop para Windows 10 ou Docker para Windows Server.
(Recomendado) Verifique se o host pode usar a conta gMSA executando Test-ADServiceAccount. Se o comando retornar False, siga as instruções de solução de problemas .
# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell # To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0' # To install the AD module on older versions of Windows 10, see https://aka.ms/rsat Test-ADServiceAccount WebApp01
Caso de uso para preparar o host de contêiner para um host de contêiner não associado ao domínio
Ao usar o gMSA para contêineres do Windows em hosts de contêiner não associados ao domínio, cada host de contêiner deve ter um plug-in para ccg.exe instalado que será usado para recuperar a conta de usuário portátil e as credenciais especificadas na etapa anterior. Os plug-ins são exclusivos da pasta secreta usada para proteger as credenciais da conta de usuário móvel. Por exemplo, plug-ins diferentes seriam necessários para armazenar credenciais de conta no Cofre de Chaves do Azure versus em um repositório secreto do Kubernetes.
Atualmente, o Windows não oferece um plug-in interno padrão. As instruções de instalação para plug-ins serão específicas da implementação. Para obter mais informações sobre como criar e registrar plug-ins para ccg.exe, consulte interface ICcgDomainAuthCredentials.
Criar uma especificação de credencial
Um arquivo de especificação de credenciais é um documento JSON que contém metadados sobre a(s) conta(s) gMSA que você deseja que um contêiner use. Ao manter a configuração de identidade separada da imagem do contêiner, você pode alterar qual gMSA o contêiner usa simplesmente trocando o arquivo de especificação de credencial, sem alterações de código são necessárias.
O arquivo de especificação de credenciais é criado usando o módulo CredentialSpec PowerShell em uma máquina associada a um domínio. Depois de criar o arquivo, você pode copiá-lo para outros hosts de contêiner ou para seu orquestrador de contêiner. O arquivo de especificação de credenciais não contém segredos, como a senha gMSA, uma vez que o host do contêiner recupera o gMSA em nome do contêiner.
O Docker espera encontrar o arquivo de especificação de credenciais no diretório CredentialSpecs no diretório de dados do Docker. Em uma instalação padrão, você encontrará essa pasta em C:\ProgramData\Docker\CredentialSpecs
.
Para criar um arquivo de especificação de credenciais no host do contêiner:
Instalar as ferramentas do RSAT AD PowerShell
- Para o Windows Server, execute Install-WindowsFeature RSAT-AD-PowerShell.
- Para o Windows 10, versão 1809 ou posterior, execute Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'.
- Para versões mais antigas do Windows 10, consulte https://aka.ms/rsat.
Execute o cmdlet a seguir para instalar a versão mais recente do módulo PowerShell do CredentialSpec:
Install-Module CredentialSpec
Se você não tiver acesso à Internet em seu host de contêiner, execute
Save-Module CredentialSpec
em uma máquina conectada à Internet e copie a pasta do módulo paraC:\Program Files\WindowsPowerShell\Modules
ou para outro local em$env:PSModulePath
no host do contêiner.Execute o seguinte cmdlet para criar o novo arquivo de especificação de credencial:
# Replace 'WebApp01' with your own gMSA New-CredentialSpec -AccountName WebApp01
Por padrão, o cmdlet criará uma especificação de credencial usando o nome gMSA fornecido como a conta de computador para o contêiner. O arquivo será salvo no diretório Docker CredentialSpecs usando o domínio gMSA e o nome da conta para o nome do arquivo.
Se você quiser salvar o arquivo em outro diretório, use o parâmetro
-Path
:New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
Você também pode criar uma especificação de credencial que inclua contas gMSA adicionais se estiver executando um serviço ou processo como um gMSA secundário no contêiner. Para fazer isso, use o parâmetro
-AdditionalAccounts
:New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
Para obter uma lista completa dos parâmetros suportados, execute
Get-Help New-CredentialSpec -Full
.Você pode mostrar uma lista de todas as especificações de credenciais e seu caminho completo com o seguinte cmdlet:
Get-CredentialSpec
Este é um exemplo de uma especificação de credencial:
{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
]
}
}
Configuração adicional de especificação de credenciais para caso de uso de host de contêiner não associado ao domínio
Ao usar o gMSA com hosts de contêiner não associados ao domínio, as informações sobre o plug-in de ccg.exe que você usará precisam ser adicionadas à especificação de credencial. Isso será adicionado a uma seção da especificação de credencial chamada HostAccountConfig. A seção HostAccountConfig tem três campos que precisam ser preenchidos:
- PortableCcgVersion: Deve ser definido como "1".
- PluginGUID: O COM CLSID para o plug-in ccg.exe. Isso é exclusivo do plug-in que está sendo usado.
- PluginInput: Entrada específica do plug-in para obter informações da conta de utilizador do repositório secreto.
Este é um exemplo de uma especificação de credencial com a seção HostAccountConfig adicionada:
{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
],
"HostAccountConfig": {
"PortableCcgVersion": "1",
"PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
"PluginInput": "contoso.com:gmsaccg:<password>"
}
}
}
Próximos passos
Agora que você configurou sua conta gMSA, você pode usá-la para:
Se tiver algum problema durante a configuração, consulte o nosso guia de resolução de problemas para obter possíveis soluções.