Configurar gMSA (Contas de Serviço Gerenciado) de grupo para contêineres do Windows com o Serviço de Kubernetes do Azure no Windows Server

Aplica-se a: AKS no Windows Server

Para usar a Autenticação do AD, você pode configurar Contas de Serviço Gerenciadas por Grupo (gMSA) para contêineres do Windows serem executados em um host que não é parte do domínio. Uma Conta de Serviço Gerenciado de grupo é um tipo especial de conta de serviço introduzida no Windows Server 2012 projetada para permitir que vários computadores compartilhem uma identidade sem saber a senha. Contêineres do Windows não podem ser ingressados no domínio, mas muitos aplicativos executados neles ainda precisam de autenticação do Active Directory.

Arquitetura da gMSA para contêineres com um host sem domínio associado

O gMSA para contêineres com um host sem domínio associado usa uma identidade de usuário portátil em vez de uma identidade de host para recuperar as credenciais do gMSA. Portanto, você não precisa adicionar manualmente nodos de trabalho do Windows a um domínio. A identidade do usuário é salva como um segredo no Kubernetes. O diagrama a seguir mostra o processo de configuração da gMSA para contêineres com um host não associado a um domínio.

A gMSA para contêineres com um host não ingressado no domínio fornece a flexibilidade de criar contêineres com a gMSA sem ingressar o nó do host no domínio. A partir do Windows Server 2019, há suporte para ccg.exe, o que 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 ccg.exe, consulte Interface ICcgDomainAuthCredentials.

Comparação de gMSA para contêineres com um host não associado ao domínio e um host associado ao domínio

Quando a gMSA foi introduzida inicialmente, ela exigia que o host do contêiner fosse vinculado ao domínio, o que criava muito trabalho extra para manualmente vincular nós de trabalho do Windows a um domínio. Essa limitação foi tratada com gMSA para contêineres com um host não associado ao domínio, portanto, agora você pode usar gMSA com hosts não associados ao domínio. Outras melhorias no gMSA incluem os seguintes recursos:

• Eliminando o requisito de ingressar manualmente nós de trabalho do Windows em um domínio. Para cenários de dimensionamento, essa simplificação ajuda.
• Em cenários de atualização contínua, você não precisa mais reafiliar o nó a um domínio.
• Um processo mais fácil para gerenciar as contas de computador do nó de trabalho a fim de recuperar senhas de conta de serviço gMSA.
• Um processo de ponta a ponta menos complicado para configurar a gMSA com o Kubernetes.

Antes de começar

Para executar um contêiner do Windows com uma conta de serviço gerenciado de grupo, você precisa dos seguintes pré-requisitos:

• 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á requisitos de nível funcional de floresta ou domínio para usar gMSAs, mas apenas controladores de domínio que executam o Windows Server 2012 ou posterior podem distribuir senhas gMSA. 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ê deve ser um Administrador de Domínio ou usar uma conta que tenha permissões para 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 seu computador de desenvolvimento ou host do contêiner.
• Para garantir que a autenticação gMSA e AD funcionem, verifique se os nós de cluster do Windows Server estão configurados para sincronizar seu tempo com um controlador de domínio ou outra fonte de tempo. Você também deve verificar se o Hyper-V está configurado para sincronizar a hora com qualquer máquina virtual.

Preparar a gMSA no controlador de domínio

Siga estas etapas para preparar o gMSA no controlador de domínio:

1. No controlador de domínio, prepare o Active Directory e crie a conta gMSA.

2. Crie uma conta de usuário de domínio. Salve esta conta de usuário e credenciais de senha como um segredo do Kubernetes. Use essas credenciais para recuperar a senha gMSA.

3. Para criar uma conta gMSA e conceder permissão para ler a senha da conta gMSA criada na Etapa 2, execute o seguinte comando New-ADServiceAccount PowerShell:

    New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier> 
   

   Para -PrincipalsAllowedToRetrieveManagedPassword, especifique o nome de usuário de domínio criado anteriormente, conforme mostrado no exemplo a seguir:

   New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"
   

Preparar o arquivo JSON de especificação de credencial gMSA

Para preparar o arquivo JSON de especificação de credencial gMSA, siga as etapas para criar uma especificação de credencial.

Configurar gMSA para pods e contêineres do Windows no cluster

A comunidade do Kubernetes já oferece suporte a nós de trabalho do Windows ingressados no domínio para gMSA. Embora você não precise ingressar no domínio de um nó de trabalho do Windows no AKS no Windows Server, você precisa concluir outras etapas de configuração. Essas etapas incluem a instalação do webhook, a definição de recurso personalizado (CRD) e a especificação de credencial e a habilitação do controle de acesso baseado em função (função RBAC). As etapas a seguir usam comandos do PowerShell que simplificam o processo de configuração.

Antes de concluir as etapas a seguir, instale o módulo AksHci do PowerShell e verifique se você pode se conectar ao cluster.

1. Para instalar o webhook, execute o seguinte comando Install-AksHciGmsaWebhook do PowerShell:

   Install-AksHciGMSAWebhook -Name <cluster name>
   

   Para validar se o pod do webhook está em execução, execute o seguinte comando:

   kubectl get pods -n kube-system | findstr gmsa
   

   Você deve ver um pod com o prefixo gmsa-webhook que está em execução.

2. Crie o objeto secreto que armazena a credencial de usuário do Active Directory. Preencha os dados de configuração a seguir e salve as configurações em um arquivo chamado secret.yaml.

   apiVersion: v1
   kind: Secret
   metadata:
      name: <secret-name>
      namespace: <secret under namespace other than the default>
   type: Opaque
   stringData:
      domain: <FQDN of the domain, for example: akshcitest.com>
      username: <domain user who can retrieve the gMSA password>
      password: <password>
   

   Em seguida, execute o seguinte comando para criar o objeto secreto:

   kubectl apply -f secret.yaml
   

   Observação

   Se você criar um segredo em um namespace diferente do padrão, lembre-se de definir o namespace da implantação para o mesmo namespace.

3. Use o cmdlet Add-AksHciGMSACredentialSpec do PowerShell para criar o CRD gMSA, habilitar o RBAC (controle de acesso baseado em função) e atribuir a função às contas de serviço para usar um arquivo de especificação de credencial gMSA específico. Essas etapas são descritas com mais detalhes neste artigo do Kubernetes sobre Configurar gMSA para pods e contêineres do Windows.

   Use a especificação de credencial JSON como entrada para o seguinte comando do PowerShell (parâmetros com asteriscos * são obrigatórios):

   Add-AksHciGMSACredentialSpec -Name <cluster name>*  
     -credSpecFilePath <path to JSON credspec>* 
     -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
     -secretName <name of secret>* 
     -secretNamespace <namespace of secret>  
     -serviceAccount <name of service account to bind to clusterrole>  
     -clusterRoleName <name of clusterrole to use the credspec>*  
     -overwrite 
   

   Para exibir um exemplo, consulte o seguinte código:

   Add-AksHciGMSACredentialSpec -Name mynewcluster 
     -credSpecFilePath .\credspectest.json 
     -credSpecName credspec-mynewcluster 
     -secretName mysecret 
     -clusterRoleName clusterrole-mynewcluster
   

Implantar o aplicativo

Crie o arquivo YAML de implantação usando as configurações de exemplo a seguir. As entradas obrigatórias incluem serviceAccountName, gmsaCredentialSpecName, volumeMountse dnsconfig.

1. Adicione a conta de serviço:

   serviceAccountName: default
      securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName:
   

2. Adicione o objeto de especificação de credencial:

   securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName: <cred spec name>
   

3. Monte o segredo para a implantação:

   volumeMounts:
        - name: <volume name>
          mountPath: <vmount path>
          readOnly: true
      volumes:
        - name: <volume name>
          secret:
            secretName: <secret name>
            items:
              - key: username
                path: my-group/my-username
   

4. Adicione o endereço IP do controlador de domínio e o nome de domínio em dnsConfig:

   dnsConfig: 
        nameservers:
          - <IP address for domain controller>
        searches: 
          - <domain>
   

Verifique se o contêiner está funcionando com gMSA

Depois de implantar o contêiner, use as seguintes etapas para verificar se ele está funcionando:

1. Obtenha a ID do contêiner para sua implantação executando o seguinte comando:

   kubectl get pods
   

2. Abra o PowerShell e execute o seguinte comando:

   kubectl exec -it <container id> powershell
   

3. Depois de estar no contêiner, execute o seguinte comando:

   Nltest /parentdomain 
   Nltest /sc_verify:<domain> 
   

   Connection Status = 0 0x0 NERR_Success The command completed successfully. 
   

   Essa saída mostra que o computador foi autenticado por um controlador de domínio e existe um canal seguro entre o computador cliente e o controlador de domínio.

4. Verifique se o contêiner pode obter um TGT (tíquete de concessão de tíquete) válido do Kerberos.

   klist get krbtgt
   

   A ticket to krbtgt has been retrieved successfully
   

Limpar as configurações de gMSA no cluster

Se você precisar limpar as configurações da gMSA, use as etapas de desinstalação a seguir.

Desinstalar a especificação de credencial

Para desinstalar, execute o seguinte comando Remove-AksHcigmsaCredentialSpec do PowerShell:

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

Desinstalar webhook

Para desinstalar o webhook, execute o seguinte comando Uninstall-AksHciGMSAWebhook do PowerShell:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Próximas etapas

• Usar volume persistente em um cluster do Kubernetes
• Monitorar o AKS em clusters do Windows Server