Partilhar via

Criar gMSAs para contêineres do Windows

  • Artigo

Aplica-se a: Windows Server 2022, Windows Server 2019

As redes baseadas em Windows normalmente usam o Active Directory (AD) para facilitar a autenticação e a autorização entre usuários, computadores e outros recursos de rede. Os desenvolvedores de aplicativos empresariais geralmente criam seus aplicativos para serem integrados ao AD e executados em servidores ingressados no domínio para aproveitar a Autenticação Integrada do Windows, o que torna mais fácil para os usuários e outros serviços entrarem de forma automática e transparente no aplicativo com suas identidades. Este artigo explica como começar a usar contas de serviço gerenciado de grupo do Active Directory com contêineres do Windows.

Embora os contêineres do Windows não possam ser ingressados no domínio, eles ainda podem usar as identidades de domínio do Active Directory para dar suporte a vários cenários de autenticação. Para isso, você pode configurar um contêiner do Windows para ser executado com uma gMSA (Conta de Serviço Gerenciado de grupo), que é um tipo especial de conta de serviço introduzido no Windows Server 2012 e criado para permitir que vários computadores compartilhem uma identidade sem precisar saber a senha dela. Os contêineres do Windows não podem ser ingressados no 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 gMSA (Conta de Serviço Gerenciado de grupo).

Quando a gMSA para contêineres do Windows foi introduzida, ela exigia que o host de contêiner fosse conectado ao domínio. Isso criou uma grande sobrecarga para os usuários que precisavam adicionar de modo manual nós de trabalho do Windows a um domínio. Essa limitação foi resolvida com o suporte gMSA para contêineres do Windows em hosts de contêiner não conectado ao domínio. A funcionalidade gMSA original continuará sendo compatível para o uso de um host de contêiner ingressado no domínio.

Os aprimoramentos na gMSA ao usar um host de contêiner não conectado ao domínio incluem:

  • Eliminação do requisito de ingressar manualmente nós de trabalho do Windows em um domínio, o que causava muita sobrecarga para os usuários. Para cenários de escala, o uso de um host de contêiner não conectado ao domínio simplifica o processo.
  • Em cenários de atualização constante, os usuários não precisam mais reingressar o nó em um domínio.
  • Um processo mais fácil para gerenciar as contas de computador do nó de trabalho a fim de recuperar senhas de contas de serviço da gMSA.
  • Um processo de ponta a ponta menos complicado para configurar a gMSA com o Kubernetes.

Observação

Para saber como a comunidade do Kubernetes dá suporte ao uso de gMSA com contêineres do Windows, confira Configurando a gMSA.

Arquitetura e aprimoramentos da gMSA

Para lidar com as limitações da implantação inicial da gMSA para contêineres do Windows, o novo suporte gMSA para hosts de contêiner não conectados ao domínio usa uma identidade de usuário portátil, em vez de uma conta de computador host para recuperar as credenciais gMSA. Portanto, a junção manual dos nós de trabalho do Windows a um domínio não é mais necessária, embora ainda tenha suporte. A identidade/credencial do usuário é armazenada em um repositório de segredos acessível ao host de contêiner (como um segredo do Kubernetes), em que os usuários autenticados podem recuperá-la.

Diagram of group Managed Service Accounts version two

O suporte gMSA para hosts de contêiner não conectados ao domínio fornece a flexibilidade de criar contêineres com a gMSA sem a necessidade de adicionar um nó do host ao domínio. O ccg.exe é compatível do Windows Server 2019 em diante. Isso permite que um mecanismo de plug-in recupere credenciais gMSA do Active Directory. Você pode usar essa identidade para iniciar o contêiner. Para obter mais informações sobre esse mecanismo de plug-in, confira a interface ICcgDomainAuthCredentials.

Observação

No Serviço de Kubernetes do Azure no Azure Stack HCI, é possível usar o plug-in para estabelecer uma comunicação entre o ccg.exe e o AD, depois recuperar as credenciais gMSA. Para obter mais informações, confira como Configurar a Conta de Serviço Gerenciado do grupo usando o AKS no Azure Stack HCI.

Confira o diagrama abaixo para seguir as etapas do processo do Container Credential Guard:

  1. Ao usar um arquivo CredSpec como entrada, o processo ccg.exe será iniciado no host do nó.

  2. O ccg.exe usa informações do arquivo CredSpec para iniciar um plug-in, depois recuperar as credenciais da conta do repositório de segredos associado ao plug-in.

  3. O ccg.exe usa as credenciais de conta recuperadas para recuperar a senha gMSA do AD.

  4. O ccg.exe disponibiliza a senha gMSA para um contêiner que solicitou as credenciais.

  5. O contêiner é autenticado no controlador de domínio usando a senha da gMSA para obter um TGT (tíquete de concessão de tíquete) do Kerberos.

  6. Aplicativos em execução como Serviço de Rede ou Sistema Local no contêiner agora podem autenticar e acessar recursos de domínio, como a gMSA.

    Diagram of the ccg.exe process

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 Active Directory com pelo menos um controlador de domínio que executa o Windows Server 2012 ou posterior. Não há nenhum requisito de nível funcional de floresta ou de domínio para usar gMSAs, mas as senhas de 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 Active Directory para gMSAs.
  • Permissão para criar uma conta gMSA. Para criar uma conta gMSA, você precisará ser um administrador de domínio ou usar uma conta que tenha sido delegada a permissão para criar objetos msDS-GroupManagedServiceAccount.
  • Acesso à Internet para baixar o módulo do PowerShell do CredentialSpec. Se você estiver trabalhando em um ambiente desconectado, poderá salvar o módulo em um computador com acesso à Internet e copiá-lo para seu computador de desenvolvimento ou host do contêiner.

Preparação única do Active Directory

Se você ainda não criou uma gMSA em seu domínio, precisará gerar a chave raiz do KDS (Serviço de Distribuição de Chaves). O KDS é responsável por criar, girar e liberar a senha da gMSA para hosts autorizados. Quando um host de contêiner precisar usar a 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 um administrador de domínio em um controlador de domínio ou membro do domínio com as ferramentas do PowerShell para Active Directory 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 gerenciado de grupo. Caso contrário, continue para criar a chave raiz do KDS.

Importante

Você deve criar apenas uma chave raiz do KDS por floresta. Se várias chaves raiz do KDS forem criadas, isso fará com que a gMSA comece a falhar depois que a senha da gMSA for girada.

Em um ambiente de produção ou ambiente de teste com vários controladores de domínio, execute o seguinte cmdlet no PowerShell como administrador de domínio para criar a chave raiz KDS.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Apesar de o comando implicar que a chave será efetivada imediatamente, você precisará aguardar 10 horas antes que a chave raiz do KDS seja replicada e 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 a ser efetivada 10 horas atrás.

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

Todos os contêineres que usam a Autenticação Integrada do Windows precisam de pelo menos uma gMSA. A gMSA primária é usada sempre que os aplicativos em execução como um sistema ou um serviço de rede acessam recursos na rede. O nome da 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 de computador do contêiner.

Ao criar uma gMSA, você também cria uma identidade compartilhada que pode ser usada simultaneamente em vários computadores diferentes. O acesso à senha da gMSA é protegido por uma lista do Serviço de Controle de Acesso do Microsoft Azure AD. É recomendável 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.

Por fim, como os contêineres não registram automaticamente nenhum SPN (Nomes de Entidade de Serviço), você precisará criar manualmente pelo menos um SPN de host para sua conta gMSA.

Normalmente, o host ou o SPN http é registrado usando o mesmo nome que a conta gMSA, mas talvez você precise usar um nome de serviço diferente se os clientes acessarem o aplicativo em contêiner por trás de um balanceador de carga ou um nome DNS diferente do nome da gMSA.

Por exemplo, se a conta gMSA for denominada “WebApp01”, mas os 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 uma gMSA.

propriedade da gMSA Valor necessário Exemplo
Nome Qualquer nome da conta válido. WebApp01
DNSHostName O nome de domínio acrescentado ao nome da conta. WebApp01.contoso.com
ServicePrincipalNames Defina pelo menos o SPN do host e adicione outros protocolos conforme necessário. 'host/WebApp01', 'host/WebApp01.contoso.com'
PrincipalsAllowedToRetrieveManagedPassword O grupo de segurança que contém os hosts do contêiner. WebApp01Hosts

Depois de decidir o nome da sua gMSA, execute os seguintes cmdlets no PowerShell para criar o grupo de segurança e a gMSA.

Dica

Você precisará usar uma conta que pertença ao grupo de segurança Administradores de Domínio ou que tenha recebido a permissão Criar objetos msDS-GroupManagedServiceAccount para executar os comandos a seguir. O cmdlet New-ADServiceAccount faz parte das ferramentas do PowerShell para Active Directory das Ferramentas de Administração de Servidor Remoto.

Recomendamos criar contas gMSA separadas para ambientes de desenvolvimento, teste e produção.

Caso de uso de criação de uma conta da gMSA para hosts de contêiner ingressados 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 de criação de uma conta da gMSA para hosts de contêiner não conectados ao domínio

Ao usar a gMSA para contêineres com hosts não conectados ao 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"

Preparar o host do contêiner

Caso de uso de preparação do host de contêiner para se tornar ingressado no domínio

Cada host do contêiner que executará um contêiner do Windows com uma gMSA deve estar ingressado no domínio e ter acesso para recuperar a senha da gMSA.

  1. Adicione seu computador ao seu domínio do Active Directory.

  2. Verifique se o host pertence ao grupo de segurança que controla o acesso à senha da gMSA.

  3. Reinicie o computador para obter a nova associação de grupo.

  4. Configure o Docker Desktop for Windows 10 ou o Docker for Windows Server.

  5. (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 de preparação do host de contêiner para se tornar não conectado ao domínio

Ao usar a gMSA para contêineres do Windows em hosts de contêiner não conectados ao domínio, cada host de contêiner deverá instalar um plug-in para o ccg.exe. Isso será usado para recuperar a conta de usuário portátil e as credenciais indicadas na etapa anterior. Os plug-ins são exclusivos do repositório de segredos, bem como usados para proteger as credenciais da conta de usuário portátil. Por exemplo, será preciso usar diferentes plug-ins para armazenar credenciais de conta no Azure Key Vault em comparação a um repositório de segredos do Kubernetes.

No momento, o Windows não fornece um plug-in padrão integrado. As instruções de instalação de plug-ins serão específicas para a implantação. Para obter mais informações sobre como criar e registrar plug-ins para o ccg.exe, confira a interface ICcgDomainAuthCredentials.

Criar uma especificação de credencial

Um arquivo de especificação de credencial é um documento JSON que contém metadados sobre as contas gMSA que você deseja que um contêiner use. Ao manter a configuração de identidade separada da imagem de contêiner, é possível alterar qual gMSA o contêiner usa apenas trocando o arquivo de especificação de credencial. Além disso, não é necessário usar alterações de código.

O arquivo de especificação de credencial será criado com o módulo CredentialSpec PowerShell em computador conectado ao domínio. Após a criação, copie o arquivo para outros hosts de contêiner ou para o orquestrador de contêineres. O arquivo de especificação de credencial não contém segredos, como a senha da gMSA, já que o host do contêiner recupera a gMSA em nome do contêiner.

O Docker espera encontrar o arquivo de especificação de credencial no diretório CredentialSpecs, que está 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 credencial no host do contêiner:

  1. Instalar as ferramentas RSAT do PowerShell para Active Directory

    • 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.

  2. Execute o seguinte cmdlet para instalar a versão mais recente do módulo CredentialSpec do PowerShell:

    Install-Module CredentialSpec

    Caso não tenha acesso à Internet no host de contêiner, execute Save-Module CredentialSpec em um computador conectado à Internet, depois copie a pasta do módulo para C:\Program Files\WindowsPowerShell\Modules. Como alternativa, use outro local em $env:PSModulePath no host de contêiner.

  3. 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 uma conta de computador para o contêiner. O arquivo será salvo no diretório CredentialSpecs do Docker usando o nome de conta e o domínio da gMSA para o nome de 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 uma gMSA secundária 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 com suporte, execute Get-Help New-CredentialSpec -Full.

  4. Você pode mostrar uma lista de todas as especificações de credencial e seu caminho completo com o seguinte cmdlet:

    Get-CredentialSpec

Este é um exemplo de 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"
            }
        ]
    }
}

Uma configuração adicional de especificação de credencial para o caso de uso de hosts de contêiner não conectados ao domínio

Ao usar a gMSA com hosts de contêiner não conectados ao domínio, as informações sobre o plug-in ccg.exe precisarão ser adicionadas à especificação de credencial. Isso será adicionado a uma seção de especificação de credencial chamada HostAccountConfig. É preciso preencher três campos da seção HostAccountConfig:

  • PortableCcgVersion: recomendamos definir como "1".
  • PluginGUID: o COM CLSID do plug-in ccg.exe. Ele é exclusivo para o plug-in que está sendo usado.
  • PluginInput: entrada específica do plug-in usada para recuperar informações da conta de usuário do repositório de segredos.

Veja abaixo o 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óximas etapas

Agora que você configurou sua conta gMSA, você pode usá-la para:

Se você tiver problemas durante a instalação, consulte nosso guia de solução de problemas para obter soluções possíveis.

Recursos adicionais