Konfigurowanie kont usług zarządzanych przez grupę (gMSA) dla kontenerów systemu Windows przy użyciu Azure Kubernetes Service w usłudze Azure Stack HCI i systemie Windows Server

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie 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ę to specjalny typ konta usługi wprowadzonego w Windows Server 2012, który umożliwia wielu komputerom udostępnianie 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 używanie konta gMSA z kontenerami systemu Windows, zobacz Konfigurowanie konta gMSA.

Architektura konta zarządzanego przez grupę dla kontenerów z hostem nieprzyłączonych do domeny

Usługa gMSA dla kontenerów z hostem nieprzyłączonych do domeny używa tożsamości użytkownika przenośnego zamiast tożsamości hosta do pobierania poświadczeń konta zarządzanego przez grupę. W związku z tym ręczne przyłą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 konta zarządzanego przez grupę 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ą konta zarządzanego przez grupę 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. Możesz użyć tej tożsamości do uruchomienia kontenera. Aby uzyskać więcej informacji na temat ccg.exe, zobacz interfejs ICcgDomainAuthCredentials.

Porównanie konta zarządzanego przez grupę dla kontenerów z hostem nieprzyłączonych do domeny i hostem przyłączonym do domeny

Po początkowym wprowadzeniu konta zarządzanego przez grupę host kontenera musi zostać przyłączony do domeny, co spowodowało wiele narzutów na ręczne dołączanie węzłów roboczych systemu Windows do domeny. To ograniczenie zostało rozwiązane w przypadku 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 niezałączonych do domeny. 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 komputera węzła roboczego w celu pobrania haseł konta usługi gMSA.
• Mniej skomplikowany proces kompleksowego konfigurowania konta zarządzanego przez usługę Kubernetes.

Zanim rozpoczniesz

Aby uruchomić kontener systemu Windows z kontem 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 żadnych wymagań dotyczących poziomu funkcjonalności lasu lub domeny do korzystania z konta zarządzanego przez 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 gMSA).
• 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 bez połączenia, 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 azure Stack HCI i Windows Server 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 grupy na kontrolerze domeny

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

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

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

3. Aby utworzyć konto GMSA i udzielić uprawnienia 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 konta 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 robocze systemu Windows dla konta gMSA. Mimo że nie musisz dołączać do domeny węzła procesu roboczego systemu Windows w usłudze AKS w usłudze Azure Stack HCI i systemie Windows Server, istnieją inne wymagane kroki konfiguracji. Te kroki obejmują instalowanie elementu webhook, niestandardową definicję zasobu (CRD) i specyfikację poświadczeń oraz włączanie kontroli dostępu opartej na rolach (rola RBAC). W poniższych krokach są używane polecenia programu PowerShell utworzone w celu uproszczenia procesu konfiguracji.

Przed wykonaniem poniższych kroków upewnij się, że moduł AksHci programu PowerShell 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. Twórca 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 Add-AksHciGMSACredentialSpec programu PowerShell, aby utworzyć grupę 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 w temacie Configure gMSA for Windows pods and containers (Konfigurowanie konta 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

Twórca pliku YAML wdrożenia przy użyciu następujących przykładowych ustawień. Wymagane wpisy obejmują serviceAccountName, gmsaCredentialSpecName, volumeMountsi 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 wejś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ń konta zarządzanego przez grupę w klastrze

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

Odinstalowywanie specyfikacji poświadczeń

Aby odinstalować program PowerShell, 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 Programu PowerShell Uninstall-AksHciGMSAWebhook :

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Następne kroki

• Używanie trwałego woluminu w klastrze Kubernetes
• Monitorowanie usługi AKS w klastrach azure Stack HCI i Windows Server