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

  • Artigo

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

Observação

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

Arquitetura de 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 de gMSA. Portanto, não é mais necessário ingressar manualmente nós de trabalho do Windows em 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 ingressado no domínio:

Diagrama das Contas de Serviço Gerenciado de grupo, versão dois

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 criou muita sobrecarga para unir nós de trabalho do Windows manualmente a um domínio. Essa limitação foi resolvida com gMSA para contêineres com um host não ingressado no domínio, portanto, os usuários agora podem usar gMSA com hosts não associados ao domínio. Outros aprimoramentos na gMSA incluem o seguinte:

  • Eliminar o requisito de ingressar manualmente nós de trabalho do Windows em um domínio, o que causou muita sobrecarga. Para cenários de escala, isso simplificará 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 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á 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 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 recebido a permissão para criar objetos msDS-GroupManagedServiceAccount.
  • Acesso à Internet para baixar o módulo CredentialSpec do 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 Azure Stack HCI e 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 o tempo com as máquinas virtuais.

Preparar a gMSA no controlador de domínio

Siga as etapas abaixo 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. Criar uma conta de usuário de domínio. Essa conta de usuário/senha será salva como um segredo do Kubernetes e usada 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 Do PowerShell New-ADServiceAccount :

     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 do domínio criado anteriormente, conforme mostrado no exemplo abaixo:

    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á dá 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 Stack HCI e no Windows Server, há outras etapas de configuração necessárias. Essas etapas incluem a instalação do webhook, a CRD (definição de recurso personalizado) e a especificação de credencial, bem como 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 abaixo, verifique se o módulo do AksHci PowerShell está instalado e kubectl se 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 com êxito, execute o seguinte comando:

    kubectl get pods -n kube-system | findstr gmsa

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

  2. Crie o objeto secreto que armazena a credencial de usuário do Active Directory. Conclua os dados de configuração abaixo 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 a CRD gMSA, habilitar o RBAC (controle de acesso baseado em função) e, em seguida, atribuir a função às contas de serviço para usar um arquivo específico de especificação de credencial gMSA. Essas etapas são descritas mais detalhadamente 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 necessá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:

    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 limpo configurações de 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 do PowerShell Uninstall-AksHciGMSAWebhook :

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Próximas etapas