Konfigurowanie kont usług zarządzanych przez grupę (gMSA) dla kontenerów systemu Windows za pomocą usługi Azure Kubernetes Service na platformie Azure w systemie Lokalnym i Windows Server

Dotyczy: AKS na Azure Local 22H2, AKS na Windows Server

Aby użyć uwierzytelniania usługi AD, można skonfigurować konta usługi zarządzane przez grupę (gMSA) dla kontenerów systemu Windows do uruchamiania z hostem nieprzyłączonych do domeny. Konto usługi zarządzane przez grupę jest specjalnym typem konta usługi wprowadzonego w systemie Windows Server 2012, które zostało zaprojektowane w celu umożliwienia wielu komputerom udostępniania tożsamości bez znajomości hasła. Nie można przyłączyć kontenerów systemu Windows do domeny, ale wiele aplikacji systemu Windows uruchomionych w kontenerach systemu Windows nadal wymaga uwierzytelniania usługi AD.

Uwaga

Aby dowiedzieć się, jak społeczność platformy Kubernetes obsługuje korzystanie z konta gMSA z kontenerami systemu Windows, zobacz Konfigurowanie konta gMSA.

Architektura usługi gMSA dla kontenerów z hostem nieprzyłączonych do domeny

GMSA dla kontenerów z hostem nieprzyłączonych do domeny używa przenośnej tożsamości użytkownika zamiast tożsamości hosta do pobierania poświadczeń gMSA. W związku z tym ręczne dołączanie węzłów roboczych systemu Windows do domeny nie jest już konieczne. Tożsamość użytkownika jest zapisywana jako wpis tajny na platformie Kubernetes. Na poniższym diagramie przedstawiono proces konfigurowania usługi gMSA dla kontenerów z hostem nieprzyłączonych do domeny:

GMSA dla kontenerów z hostem nieprzyłączonych do domeny zapewnia elastyczność tworzenia kontenerów za pomocą gMSA bez dołączania węzła hosta do domeny. Począwszy od systemu Windows Server 2019, ccg.exe jest obsługiwany, co umożliwia mechanizm wtyczki do pobierania poświadczeń gMSA z usługi Active Directory. Tej tożsamości można użyć do uruchomienia kontenera. Aby uzyskać więcej informacji na temat ccg.exe, zobacz interfejs ICcgDomainAuthCredentials.

Porównanie usługi gMSA dla kontenerów z hostem nieprzyłączonych do domeny i hostem przyłączonym do domeny

Po początkowym wprowadzeniu gMSA wymagane jest, aby host kontenera został przyłączony do domeny, co spowodowało duże obciążenie, aby ręcznie dołączyć węzły robocze systemu Windows do domeny. To ograniczenie zostało rozwiązane z użyciem konta zarządzanego przez grupę dla kontenerów z hostem nieprzyłączonych do domeny, dzięki czemu użytkownicy mogą teraz używać konta gMSA z hostami niezawiązanymi z domeną. Inne ulepszenia usługi gMSA obejmują następujące funkcje:

• Wyeliminowanie wymagania ręcznego dołączania węzłów roboczych systemu Windows do domeny, co spowodowało duże obciążenie. W przypadku scenariuszy skalowania upraszcza to proces.
• W scenariuszach aktualizacji stopniowej użytkownicy nie muszą już ponownie dołączać węzła do domeny.
• Łatwiejszy proces zarządzania kontami maszyny węzła roboczego w celu pobrania haseł konta usługi gMSA.
• Mniej skomplikowany proces kompleksowego konfigurowania usługi gMSA przy użyciu platformy Kubernetes.

Zanim rozpoczniesz

Aby uruchomić kontener systemu Windows przy użyciu konta usługi zarządzanej przez grupę, potrzebne są następujące wymagania wstępne:

• Domena usługi Active Directory z co najmniej jednym kontrolerem domeny z systemem Windows Server 2012 lub nowszym. Nie ma wymagań dotyczących poziomu funkcjonalności lasu lub domeny do używania zasad grupy, ale tylko kontrolery domeny z systemem Windows Server 2012 lub nowszym mogą dystrybuować hasła gMSA. Aby uzyskać więcej informacji, zobacz Active Directory requirements for gMSAs (Wymagania dotyczące usługi Active Directory dla kont zasad grupy).
• Uprawnienie do tworzenia konta gMSA. Aby utworzyć konto gMSA, musisz być administratorem domeny lub użyć konta z uprawnieniami do tworzenia obiektów msDS-GroupManagedServiceAccount .
• Dostęp do Internetu w celu pobrania modułu CredentialSpec programu PowerShell. Jeśli pracujesz w środowisku odłączonym, możesz zapisać moduł na komputerze z dostępem do Internetu i skopiować go na komputer deweloperski lub host kontenera.
• Aby upewnić się, że usługi gMSA i AD działają prawidłowo, upewnij się, że węzły klastra lokalnego i Windows Server platformy Azure są skonfigurowane do synchronizowania czasu z kontrolerem domeny lub innym źródłem czasu. Należy również upewnić się, że funkcja Hyper-V jest skonfigurowana do synchronizowania czasu z dowolnymi maszynami wirtualnymi.

Przygotowywanie konta zarządzanego przez klienta na kontrolerze domeny

Wykonaj następujące kroki, aby przygotować konto zarządzane przez administratora domeny na kontrolerze domeny:

1. Na kontrolerze domeny przygotuj usługę Active Directory i utwórz konto gMSA.

2. Utwórz konto użytkownika domeny. Te poświadczenia konta użytkownika/hasła są zapisywane jako wpis tajny kubernetes i używane do pobierania hasła gMSA.

3. Aby utworzyć konto GMSA i udzielić uprawnień do odczytu hasła dla konta gMSA utworzonego w kroku 2, uruchom następujące polecenie New-ADServiceAccount programu 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> 
   

   W polu -PrincipalsAllowedToRetrieveManagedPasswordokreśl nazwę użytkownika domeny utworzoną wcześniej, jak pokazano w poniższym przykładzie:

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

Przygotowywanie pliku JSON specyfikacji poświadczeń gMSA

Aby przygotować plik JSON specyfikacji poświadczeń gMSA, wykonaj kroki tworzenia specyfikacji poświadczeń.

Konfigurowanie usługi gMSA dla zasobników i kontenerów systemu Windows w klastrze

Społeczność platformy Kubernetes obsługuje już przyłączone do domeny węzły procesów roboczych systemu Windows dla grupy GMSA. Mimo że nie musisz przyłączać do domeny węzła procesu roboczego systemu Windows w usłudze AKS w usłudze Azure Local i Windows Server, istnieją inne wymagane kroki konfiguracji. Te kroki obejmują instalowanie elementu webhook, niestandardową definicję zasobu (CRD) oraz specyfikację poświadczeń oraz włączanie kontroli dostępu opartej na rolach (rola RBAC). W poniższych krokach są używane polecenia programu PowerShell, które są kompilowane, aby uprościć proces konfiguracji.

Przed wykonaniem poniższych kroków upewnij się, że moduł programu PowerShell usługi AksHci jest zainstalowany i kubectl może nawiązać połączenie z klastrem.

1. Aby zainstalować element webhook, uruchom następujące polecenie Install-AksHciGmsaWebhook programu PowerShell:

   Install-AksHciGMSAWebhook -Name <cluster name>
   

   Aby sprawdzić, czy zasobnik elementu webhook został pomyślnie uruchomiony, uruchom następujące polecenie:

   kubectl get pods -n kube-system | findstr gmsa
   

   Powinien zostać wyświetlony jeden zasobnik z prefiksem gmsa-webhook , który jest uruchomiony.

2. Utwórz obiekt wpisu tajnego, który przechowuje poświadczenia użytkownika usługi Active Directory. Wykonaj następujące dane konfiguracji i zapisz ustawienia w pliku o nazwie 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>
   

   Następnie uruchom następujące polecenie, aby utworzyć obiekt tajny:

   kubectl apply -f secret.yaml
   

   Uwaga

   Jeśli utworzysz wpis tajny w przestrzeni nazw innej niż domyślna, pamiętaj, aby ustawić przestrzeń nazw wdrożenia na tę samą przestrzeń nazw.

3. Użyj polecenia cmdlet programu PowerShell Add-AksHciGMSACredentialSpec, aby utworzyć gMSA CRD, włączyć kontrolę dostępu opartą na rolach (RBAC), a następnie przypisać rolę do kont usług, aby użyć określonego pliku specyfikacji poświadczeń gMSA. Te kroki opisano bardziej szczegółowo w tym artykule dotyczącym platformy Kubernetes dotyczącym konfigurowania usługi gMSA dla zasobników i kontenerów systemu Windows.

   Użyj specyfikacji poświadczeń JSON jako danych wejściowych dla następującego polecenia programu PowerShell (parametry z gwiazdkami * są obowiązkowe):

   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 
   

   Aby wyświetlić przykład, zobacz następujący kod:

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

Wdrażanie aplikacji

Utwórz plik YAML wdrożenia przy użyciu następujących przykładowych ustawień. Wymagane wpisy obejmują serviceAccountName, , gmsaCredentialSpecNamevolumeMountsi dnsconfig.

1. Dodaj konto usługi:

   serviceAccountName: default
      securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName:
   

2. Dodaj obiekt specyfikacji poświadczeń:

   securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName: <cred spec name>
   

3. Zainstaluj wpis tajny dla wdrożenia:

   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. Dodaj adres IP kontrolera domeny i nazwę domeny w obszarze dnsConfig:

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

Sprawdzanie, czy kontener działa z usługą gMSA

Po wdrożeniu kontenera wykonaj następujące kroki, aby sprawdzić, czy działa:

1. Pobierz identyfikator kontenera dla wdrożenia, uruchamiając następujące polecenie:

   kubectl get pods
   

2. Otwórz program PowerShell i uruchom następujące polecenie:

   kubectl exec -it <container id> powershell
   

3. Po przejściu do kontenera uruchom następujące polecenie:

   Nltest /parentdomain 
   Nltest /sc_verify:<domain> 
   

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

   Te dane wyjściowe pokazują, że komputer został uwierzytelniony przez kontroler domeny, a bezpieczny kanał istnieje między komputerem klienckim a kontrolerem domeny.

4. Sprawdź, czy kontener może uzyskać prawidłowy bilet przyznawania biletu protokołu Kerberos (TGT).

   klist get krbtgt
   

   A ticket to krbtgt has been retrieved successfully
   

Czyszczenie ustawień gMSA w klastrze

Jeśli musisz wyczyścić ustawienia gMSA, wykonaj następujące kroki odinstalowywania.

Odinstalowywanie specyfikacji poświadczeń

Aby odinstalować, uruchom następujące polecenie Remove-AksHcigmsaCredentialSpec programu 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>

Odinstalowywanie elementu webhook

Aby odinstalować element webhook, uruchom następujące polecenie Uninstall-AksHciGMSAWebhook programu PowerShell:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Następne kroki

• Używanie woluminu trwałego w klastrze Kubernetes
• Monitorowanie usługi AKS w klastrach usługi Azure Local i Windows Server