Partilhar via

Configurar contas de serviço geridas de grupo (gMSA) para contentores do Windows com Azure Kubernetes Service no Azure Stack HCI e Windows Server

  • Artigo

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

Para utilizar a Autenticação do AD, pode configurar contas de serviço geridas de grupo (gMSA) para os contentores do Windows serem executados com um anfitrião não associado a um domínio. Uma Conta de Serviço Gerida de grupo é um tipo especial de conta de serviço introduzido no Windows Server 2012 concebido para permitir que vários computadores partilhem uma identidade sem saber a palavra-passe. Os contentores do Windows não podem ser associados a um domínio, mas muitas aplicações do Windows que são executadas em contentores do Windows ainda precisam da Autenticação do AD.

Nota

Para saber como a comunidade do Kubernetes suporta a utilização de gMSA com contentores do Windows, veja Configurar gMSA.

Arquitetura da gMSA para contentores com um anfitrião não associado a um domínio

GMSA para contentores com um anfitrião não associado a um domínio utiliza uma identidade de utilizador portátil em vez de uma identidade de anfitrião para obter credenciais gMSA. Por conseguinte, a associação manual de nós de trabalho do Windows a um domínio já não é necessária. A identidade do utilizador é guardada como um segredo no Kubernetes. O diagrama seguinte mostra o processo de configuração de gMSA para contentores com um anfitrião não associado a um domínio:

Diagrama da versão dois das Contas de Serviço Geridas do grupo

gMSA para contentores com um anfitrião não associado a um domínio fornece a flexibilidade de criar contentores com gMSA sem associar o nó de anfitrião ao domínio. A partir do Windows Server 2019, é suportada ccg.exe, o que permite que um mecanismo de plug-in obtenha credenciais gMSA do Active Directory. Pode utilizar essa identidade para iniciar o contentor. Para obter mais informações sobre ccg.exe, veja Interface ICcgDomainAuthCredentials.

Comparação da gMSA para contentores com um anfitrião não associado a um domínio e um anfitrião associado a um domínio

Quando a gMSA foi inicialmente introduzida, era necessário que o anfitrião do contentor fosse associado a um domínio, o que criou uma grande sobrecarga para associar os nós de trabalho do Windows manualmente a um domínio. Esta limitação foi resolvida com gMSA para contentores com um anfitrião não associado a um domínio, pelo que os utilizadores podem agora utilizar gMSA com anfitriões não associados a um domínio. Outras melhorias ao gMSA incluem as seguintes funcionalidades:

  • Eliminar o requisito de associar manualmente nós de trabalho do Windows a um domínio, o que causou muitos custos gerais. Para cenários de dimensionamento, isto simplifica o processo.
  • Em cenários de atualização sem interrupção, os utilizadores já não precisam de voltar a associar o nó a um domínio.
  • Um processo mais fácil para gerir as contas de computador do nó de trabalho para obter palavras-passe da conta de serviço gMSA.
  • Um processo ponto a ponto menos complicado para configurar a gMSA com o Kubernetes.

Antes de começar

Para executar um contentor do Windows com uma conta de serviço gerida de grupo, precisa dos seguintes pré-requisitos:

  • Um domínio do Active Directory com, pelo menos, um controlador de domínio em execução Windows Server 2012 ou posterior. Não existem requisitos de nível funcional de floresta ou domínio para utilizar gMSAs, mas apenas os controladores de domínio em execução Windows Server 2012 ou posterior podem distribuir palavras-passe gMSA. Para obter mais informações, veja Requisitos do Active Directory para gMSAs.
  • Permissão para criar uma conta gMSA. Para criar uma conta gMSA, tem de ser um Administrador de Domínio ou utilizar uma conta que tenha permissões para criar objetos msDS-GroupManagedServiceAccount .
  • Acesso à Internet para transferir o módulo CredentialSpec do PowerShell. Se estiver a trabalhar num ambiente desligado, pode guardar o módulo num computador com acesso à Internet e copiá-lo para o seu computador de desenvolvimento ou anfitrião de contentor.
  • Para garantir que a autenticação gMSA e AD funcionam, certifique-se de que os nós de cluster do Azure Stack HCI e do Windows Server estão configurados para sincronizar o seu tempo com um controlador de domínio ou outra origem de tempo. Também deve certificar-se de que o Hyper-V está configurado para sincronizar o tempo com quaisquer máquinas virtuais.

Preparar o gMSA no controlador de domínio

Siga estes passos 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. Create uma conta de utilizador de domínio. Estas credenciais de conta de utilizador/palavra-passe são guardadas como um segredo do Kubernetes e utilizadas para obter a palavra-passe gMSA.

  3. Para criar uma conta GMSA e conceder permissão para ler a palavra-passe da conta gMSA criada no Passo 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 utilizador do domínio que criou anteriormente, conforme mostrado no exemplo seguinte:

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

Preparar o ficheiro JSON de especificações de credenciais gMSA

Para preparar o ficheiro JSON de especificações de credenciais gMSA, siga os passos para criar uma especificação de credencial.

Configurar gMSA para pods e contentores do Windows no cluster

A comunidade do Kubernetes já suporta nós de trabalho do Windows associados a um domínio para gMSA. Embora não precise de associar um domínio a um nó de trabalho do Windows no AKS no Azure Stack HCI e no Windows Server, existem outros passos de configuração necessários. Estes passos incluem a instalação do webhook, a definição de recursos personalizados (CRD) e a especificação de credenciais e a ativação do controlo de acesso baseado em funções (função RBAC). Os passos seguintes utilizam comandos do PowerShell criados para ajudar a simplificar o processo de configuração.

Antes de concluir os seguintes passos, certifique-se de que o módulo AksHci do PowerShell está instalado e kubectl que consegue ligar ao cluster.

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

    Install-AksHciGMSAWebhook -Name <cluster name>

    Para validar que o pod do webhook está em execução com êxito, execute o seguinte comando:

    kubectl get pods -n kube-system | findstr gmsa

    Deverá ver um pod com o prefixo gmsa-webhook em execução.

  2. Create o objeto secreto que armazena a credencial de utilizador do Active Directory. Conclua os seguintes dados de configuração e guarde as definições num ficheiro com o nome 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 criar um segredo num espaço de nomes diferente do predefinido, lembre-se de definir o espaço de nomes da implementação para o mesmo espaço de nomes.

  3. Utilize o cmdlet do PowerShell Add-AksHciGMSACredentialSpec para criar o gMSA CRD, ativar o controlo de acesso baseado em funções (RBAC) e, em seguida, atribuir a função às contas de serviço para utilizar um ficheiro de especificação de credencial gMSA específico. Estes passos são descritos mais detalhadamente neste artigo do Kubernetes sobre Configurar gMSA para pods e contentores do Windows.

    Utilize a especificação de credencial JSON como entrada para o seguinte comando do PowerShell (os 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 ver um exemplo, veja o seguinte código:

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

Implementar a aplicação

Create o ficheiro YAML de implementação com as seguintes definições de exemplo. 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 implementaçã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 contentor está a funcionar com gMSA

Depois de implementar o contentor, utilize os seguintes passos para verificar se está a funcionar:

  1. Obtenha o ID de contentor da implementação ao executar o seguinte comando:

    kubectl get pods

  2. Abra o PowerShell e execute o seguinte comando:

    kubectl exec -it <container id> powershell

  3. Assim que estiver no contentor, 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 existe um canal seguro entre o computador cliente e o controlador de domínio.

  4. Verifique se o contentor consegue obter uma Permissão de Concessão de Permissão (TGT) do Kerberos válida.

    klist get krbtgt

    A ticket to krbtgt has been retrieved successfully

Limpar as definições do gMSA no cluster

Se precisar de limpar as definições do gMSA, utilize os seguintes passos de desinstalação.

Desinstalar a especificação de credenciais

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

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>

Passos seguintes