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

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Para usar a Autenticação do AD, você pode configurar gMSA (Contas de Serviço Gerenciado) de grupo para contêineres do Windows para serem executados com um host não ingressado no 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. 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.

Arquitetura da gMSA para contêineres com um host não ingressado no domínio

A gMSA para contêineres com um host não ingressado no domínio usa uma identidade de usuário portátil em vez de uma identidade de host para recuperar credenciais da gMSA. Portanto, a junção manual dos nós de trabalho do Windows a um domínio não é mais necessária. 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 ingressado no 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 ingressado no domínio e um host ingressado no domínio

Quando a gMSA foi introduzida inicialmente, ela exigia que o host do contêiner fosse ingressado no domínio, o que criava muita sobrecarga para unir nós de trabalho do Windows manualmente a um domínio. Essa limitação foi abordada com a gMSA para contêineres com um host não ingressado no domínio, para que os usuários agora possam usar a gMSA com hosts não ingressados no domínio. Outras melhorias no gMSA incluem os seguintes recursos:

• Eliminando a necessidade de ingressar manualmente os nós de trabalho do Windows em um domínio, o que causava muita sobrecarga. Para cenários de dimensionamento, isso simplifica o processo.
• Em cenários de atualização sem interrupção, 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 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 funcione, verifique se os nós de cluster local e do Windows Server do Azure 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 a 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. Essas credenciais de conta/senha de usuário são salvas como um segredo do Kubernetes e usadas para recuperar a senha da 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 do 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 Azure Local e no Windows Server, há outras etapas de configuração necessárias. 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 criados para ajudar a simplificar o processo de configuração.

Antes de concluir as etapas a seguir, verifique se o módulo AksHci PowerShell está instalado e kubectl 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á sendo executado com êxito, 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. Quando estiver 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) Kerberos válido.

   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 locais do Azure e do Windows Server