Konfigurera grupphanterade tjänstkonton (gMSA) för Windows-containrar med Azure Kubernetes Service på Azure Local och Windows Server

Gäller för: AKS på Azure Local 22H2, AKS på Windows Server

Om du vill använda AD-autentisering kan du konfigurera grupphanterade tjänstkonton (gMSA) för Windows-containrar som ska köras med en icke-domänansluten värd. Ett grupphanterat tjänstkonto är en särskild typ av tjänstkonto som introducerades i Windows Server 2012 och som är utformat för att tillåta flera datorer att dela en identitet utan att känna till lösenordet. Windows-containrar kan inte vara domänanslutna, men många Windows-program som körs i Windows-containrar behöver fortfarande AD-autentisering.

Kommentar

Information om hur Kubernetes-communityn stöder användning av gMSA med Windows-containrar finns i Konfigurera gMSA.

Arkitektur för gMSA för containrar med en icke-domänansluten värd

gMSA för containrar med en icke-domänansluten värd använder en bärbar användaridentitet i stället för en värdidentitet för att hämta gMSA-autentiseringsuppgifter. Därför är det inte längre nödvändigt att manuellt ansluta Windows-arbetsnoder till en domän. Användaridentiteten sparas som en hemlighet i Kubernetes. Följande diagram visar processen för att konfigurera gMSA för containrar med en icke-domänansluten värd:

gMSA för containrar med en icke-domänansluten värd ger flexibiliteten att skapa containrar med gMSA utan att ansluta värdnoden till domänen. Från och med Windows Server 2019 stöds ccg.exe, vilket gör att en plugin-mekanism kan hämta gMSA-autentiseringsuppgifter från Active Directory. Du kan använda den identiteten för att starta containern. Mer information om ccg.exe finns i ICcgDomainAuthCredentials-gränssnittet.

Jämförelse av gMSA för containrar med en icke-domänansluten värd och en domänansluten värd

När gMSA ursprungligen introducerades krävde det att containervärden var domänansluten, vilket skapade mycket omkostnader för att ansluta Windows-arbetsnoder manuellt till en domän. Den här begränsningen åtgärdades med gMSA för containrar med en icke-domänansluten värd, så att användarna nu kan använda gMSA med domänosammanslutna värdar. Andra förbättringar av gMSA omfattar följande funktioner:

• Eliminerar kravet på att manuellt ansluta Windows-arbetsnoder till en domän, vilket orsakade mycket omkostnader. För skalningsscenarier förenklar detta processen.
• I scenarier med löpande uppdateringar behöver användarna inte längre ansluta noden till en domän.
• En enklare process för att hantera arbetsnodens datorkonton för att hämta gMSA-tjänstkontolösenord.
• En mindre komplicerad process från slutpunkt till slutpunkt för att konfigurera gMSA med Kubernetes.

Innan du börjar

Om du vill köra en Windows-container med ett grupphanterat tjänstkonto behöver du följande krav:

• En Active Directory-domän med minst en domänkontrollant som kör Windows Server 2012 eller senare. Det finns inga krav på skogs- eller domänfunktionsnivå för att använda gMSAs, men endast domänkontrollanter som kör Windows Server 2012 eller senare kan distribuera gMSA-lösenord. Mer information finns i Active Directory-krav för gMSAs.
• Behörighet att skapa ett gMSA-konto. Om du vill skapa ett gMSA-konto måste du vara domänadministratör eller använda ett konto som har behörighet att skapa msDS-GroupManagedServiceAccount-objekt .
• Åtkomst till Internet för att ladda ned CredentialSpec PowerShell-modulen. Om du arbetar i en frånkopplad miljö kan du spara modulen på en dator med internetåtkomst och kopiera den till utvecklingsdatorn eller containervärden.
• Se till att gMSA- och AD-autentisering fungerar genom att se till att Azure Local- och Windows Server-klusternoderna är konfigurerade för att synkronisera sin tid med antingen en domänkontrollant eller annan tidskälla. Du bör också se till att Hyper-V är konfigurerat för att synkronisera tid till virtuella datorer.

Förbereda gMSA i domänkontrollanten

Följ dessa steg för att förbereda gMSA i domänkontrollanten:

1. I domänkontrollanten förbereder du Active Directory och skapar gMSA-kontot.

2. Skapa ett domänanvändarkonto. Det här användarkontot/lösenordet sparas som en Kubernetes-hemlighet och används för att hämta gMSA-lösenordet.

3. Om du vill skapa ett GMSA-konto och bevilja behörighet att läsa lösenordet för gMSA-kontot som skapades i steg 2 kör du följande PowerShell-kommando för 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> 
   

   För -PrincipalsAllowedToRetrieveManagedPasswordanger du det domänanvändarnamn som du skapade tidigare enligt följande exempel:

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

Förbereda JSON-filen för GMSA-autentiseringsuppgifter

Om du vill förbereda JSON-filen för GMSA-autentiseringsuppgifter följer du stegen för att skapa en autentiseringsspecifikation.

Konfigurera gMSA för Windows-poddar och containrar i klustret

Kubernetes-communityn stöder redan domänanslutna Windows-arbetsnoder för gMSA. Även om du inte behöver domänansluta en Windows-arbetsnod i AKS på Azure Local och Windows Server finns det andra nödvändiga konfigurationssteg. De här stegen omfattar installation av webhooken, den anpassade resursdefinitionen (CRD) och autentiseringsspecifikationen och aktivering av rollbaserad åtkomstkontroll (RBAC-roll). Följande steg använder PowerShell-kommandon som har skapats för att förenkla konfigurationsprocessen.

Innan du slutför följande steg kontrollerar du att AksHci PowerShell-modulen är installerad och kubectl kan ansluta till klustret.

1. Installera webhooken genom att köra följande Install-AksHciGmsaWebhook PowerShell-kommando:

   Install-AksHciGMSAWebhook -Name <cluster name>
   

   Kör följande kommando för att verifiera att webhook-podden körs:

   kubectl get pods -n kube-system | findstr gmsa
   

   Du bör se en podd med prefixet gmsa-webhook som körs.

2. Skapa det hemliga objekt som lagrar Active Directory-användarautentiseringsuppgifterna. Slutför följande konfigurationsdata och spara inställningarna i en fil med namnet 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>
   

   Kör sedan följande kommando för att skapa det hemliga objektet:

   kubectl apply -f secret.yaml
   

   Kommentar

   Om du skapar en hemlighet under ett annat namnområde än standardvärdet, kom ihåg att ange namnområdet för distributionen till samma namnområde.

3. Använd PowerShell-cmdleten Add-AksHciGMSACredentialSpec för att skapa gMSA CRD, aktivera rollbaserad åtkomstkontroll (RBAC) och tilldela sedan rollen till tjänstkontona för att använda en specifik gMSA-autentiseringsspecifikationsfil. De här stegen beskrivs mer detaljerat i den här Kubernetes-artikeln om Konfigurera gMSA för Windows-poddar och -containrar.

   Använd JSON-autentiseringsspecifikationen som indata för följande PowerShell-kommando (parametrar med asterisker * är obligatoriska):

   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 
   

   Om du vill visa ett exempel läser du följande kod:

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

Distribuera programmet

Skapa YAML-distributionsfilen med hjälp av följande exempelinställningar. De obligatoriska posterna är serviceAccountName, gmsaCredentialSpecName, volumeMountsoch dnsconfig.

1. Lägg till tjänstkontot:

   serviceAccountName: default
      securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName:
   

2. Lägg till autentiseringsspecifikationsobjektet:

   securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName: <cred spec name>
   

3. Montera hemligheten för distributionen:

   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. Lägg till IP-adressen för domänkontrollanten och domännamnet under dnsConfig:

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

Kontrollera att containern fungerar med gMSA

När du har distribuerat containern använder du följande steg för att kontrollera att den fungerar:

1. Hämta container-ID:t för distributionen genom att köra följande kommando:

   kubectl get pods
   

2. Öppna PowerShell och kör följande kommando:

   kubectl exec -it <container id> powershell
   

3. När du är i containern kör du följande kommando:

   Nltest /parentdomain 
   Nltest /sc_verify:<domain> 
   

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

   Det här utdata visar att datorn autentiserades av en domänkontrollant och att det finns en säker kanal mellan klientdatorn och domänkontrollanten.

4. Kontrollera om containern kan hämta en giltig Kerberos-biljettbeviljande biljett (TGT).

   klist get krbtgt
   

   A ticket to krbtgt has been retrieved successfully
   

Rensa gMSA-inställningar i klustret

Om du behöver rensa gMSA-inställningar använder du följande avinstallationssteg.

Avinstallera autentiseringsspecifikationen

Om du vill avinstallera kör du följande Remove-AksHcigmsaCredentialSpec PowerShell-kommando:

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

Avinstallera webhook

Om du vill avinstallera webhooken kör du följande Uninstall-AksHciGMSAWebhook PowerShell-kommando:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Nästa steg

• Använda beständiga volymer i ett Kubernetes-kluster
• Övervaka AKS på Lokala Azure- och Windows Server-kluster