Partilhar via

Configurar contas de serviço gerenciado de grupo (gMSA) para contêineres do Windows com o Serviço Kubernetes do Azure no Azure Local 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 as Contas de Serviço Gerenciado (gMSA) de grupo para que os contêineres do Windows sejam executados com um host que não ingressou no domínio. Uma Conta de Serviço Gerenciado de grupo é um tipo especial de conta de serviço introduzido no Windows Server 2012 projetado para permitir que vários computadores compartilhem uma identidade sem saber a 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.

Nota

Para saber como a comunidade Kubernetes suporta o uso do gMSA com contêineres do Windows, consulte Configurar o gMSA.

Arquitetura do gMSA para contêineres com um host que não ingressou no domínio

O gMSA para contêineres com um host que não ingressou no domínio usa uma identidade de usuário portátil em vez de uma identidade de host para recuperar credenciais do gMSA. Portanto, a associação manual de 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 do gMSA para contêineres com um host que não ingressou no domínio:

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

O gMSA para contêineres com um host que não ingressou no 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 ccg.exe, consulte Interface ICcgDomainAuthCredentials.

Comparação do gMSA para contêineres com um host que não ingressou no domínio e um host ingressado no domínio

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

  • Eliminando a necessidade de unir manualmente nós de trabalho do Windows a um domínio, o que causava muita sobrecarga. Para cenários de escala, isso simplifica o processo.
  • Em cenários de atualização contínua, os usuários não precisam mais ingressar novamente o nó em um domínio.
  • Um processo mais fácil para gerenciar as contas da máquina do nó de trabalho para recuperar senhas de conta de serviço gMSA.
  • Um processo de ponta a ponta menos complicado para configurar o 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 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 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 Ative 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 sua máquina de desenvolvimento ou host de contêiner.
  • Para garantir que o gMSA e a autenticação do AD funcionem, verifique se os nós de cluster do Azure Local 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 certificar-se de que o Hyper-V está configurado para sincronizar o tempo com qualquer máquina virtual.

Preparar o 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 Ative Directory e crie a conta gMSA.

  2. Crie uma conta de usuário de domínio. Essas credenciais de conta de usuário/senha são salvas como um segredo do Kubernetes e usadas 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 credenciais gMSA

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

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

A comunidade Kubernetes já suporta nós de trabalho do Windows ingressados no domínio para gMSA. Embora você não precise ingressar em 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 personalizada (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 PowerShell:

    Install-AksHciGMSAWebhook -Name <cluster name>

    Para validar se o pod 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 em execução.

  2. Crie o objeto secreto que armazena a credencial de usuário do Ative Directory. Conclua os seguintes dados de configuração 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

    Nota

    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 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 credenciais gMSA específico. Essas etapas são descritas com mais detalhes neste artigo do Kubernetes sobre Configurar o 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

Implementar a aplicação

Crie o arquivo YAML de implantação usando as configurações de exemplo a seguir. As entradas obrigatórias incluem serviceAccountName, gmsaCredentialSpecName, volumeMounts, e 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 o 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.

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

  4. Verifique se o contêiner pode obter um Ticket Granting Ticket (TGT) Kerberos válido.

    klist get krbtgt

    A ticket to krbtgt has been retrieved successfully

Limpar as configurações do gMSA no cluster

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

Desinstale a especificação da credencial

Para desinstalar, execute o seguinte comando Remove-AksHcigmsaCredentialSpec 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 PowerShell:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Próximos passos