Udostępnij za pośrednictwem

Włączanie kont usług zarządzanych przez grupę (GMSA) dla węzłów systemu Windows Server w klastrze usługi Azure Kubernetes Service (AKS)

  • Artykuł

Konta usługi zarządzane przez grupę (GMSA) to zarządzane konto domeny dla wielu serwerów, które zapewnia automatyczne zarządzanie hasłami, uproszczone zarządzanie główną nazwą usługi (SPN) i możliwość delegowania zarządzania do innych administratorów. Za pomocą usługi Azure Kubernetes Service (AKS) można włączyć usługę GMSA w węzłach systemu Windows Server, co umożliwia kontenerom działającym w węzłach systemu Windows Server integrację z usługą GMSA i zarządzanie nimi.

Wymagania wstępne

  • Platforma Kubernetes w wersji 1.19 lub nowszej. Aby sprawdzić wersję, zobacz Sprawdzanie dostępnych uaktualnień. Aby uaktualnić wersję, zobacz Uaktualnianie klastra usługi AKS.
  • Interfejs wiersza polecenia platformy Azure w wersji 2.35.0 lub nowszej. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.
  • Tożsamości zarządzane włączone w klastrze usługi AKS.
  • Uprawnienia do tworzenia lub aktualizowania usługi Azure Key Vault.
  • Uprawnienia do konfigurowania konta GMSA w usłudze domena usługi Active Directory lub lokalna usługa Active Directory.
  • Kontroler domeny musi mieć włączone usługi sieci Web Active Directory i musi być dostępny na porcie 9389 przez klaster usługi AKS.

Uwaga

Firma Microsoft udostępnia również specjalnie utworzony moduł programu PowerShell do konfigurowania usługi gMSA w usłudze AKS. Aby uzyskać więcej informacji, zobacz gMSA w usłudze Azure Kubernetes Service.

Konfigurowanie usługi GMSA na kontrolerze domeny usługi Active Directory

Aby korzystać z usługi GMSA z usługą AKS, potrzebujesz poświadczeń użytkownika domeny standardowej, aby uzyskać dostęp do poświadczeń GMSA skonfigurowanych na kontrolerze domeny. Aby skonfigurować usługę GMSA na kontrolerze domeny, zobacz Wprowadzenie do kont usług zarządzanych przez grupę. W przypadku poświadczeń użytkownika domeny standardowej można użyć istniejącego użytkownika lub utworzyć nowego, o ile ma on dostęp do poświadczeń GMSA.

Ważne

Musisz użyć usługi domena usługi Active Directory lub lokalna usługa Active Directory. Obecnie nie można użyć identyfikatora Entra firmy Microsoft do skonfigurowania usługi GMSA z klastrem usługi AKS.

Przechowywanie poświadczeń użytkownika domeny standardowej w usłudze Azure Key Vault

Klaster usługi AKS używa poświadczeń użytkownika domeny standardowej do uzyskiwania dostępu do poświadczeń GMSA z kontrolera domeny. Aby zapewnić bezpieczny dostęp do tych poświadczeń dla klastra usługi AKS, należy je przechowywać w usłudze Azure Key Vault.

  1. Jeśli nie masz jeszcze magazynu kluczy platformy Azure, utwórz go przy użyciu az keyvault create polecenia .

    az keyvault create --resource-group myResourceGroup --name myGMSAVault

  2. Zapisz standardowe poświadczenia użytkownika domeny jako wpis tajny w magazynie kluczy przy użyciu az keyvault secret set polecenia . Poniższy przykład przechowuje poświadczenia użytkownika domeny z kluczem GMSADomainUserCred w magazynie kluczy myGMSAVault .

    az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"

    Uwaga

    Pamiętaj, aby użyć w pełni kwalifikowanej nazwy domeny dla domeny.

Opcjonalnie: użyj niestandardowej sieci wirtualnej z niestandardowym systemem DNS

Należy skonfigurować kontroler domeny za pomocą systemu DNS, aby był osiągalny przez klaster usługi AKS. Możesz skonfigurować sieć i system DNS poza klastrem usługi AKS, aby umożliwić klastrowi dostęp do kontrolera domeny. Alternatywnie możesz użyć usługi Azure CNI, aby skonfigurować niestandardową sieć wirtualną z niestandardowym systemem DNS w klastrze usługi AKS w celu zapewnienia dostępu do kontrolera domeny. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci CNI platformy Azure w usłudze Azure Kubernetes Service (AKS).

Opcjonalnie: Skonfiguruj więcej niż jeden serwer DNS

Jeśli chcesz skonfigurować więcej niż jeden serwer DNS dla usługi GMSA systemu Windows w klastrze usługi AKS, nie należy określać --gmsa-dns-serverani v--gmsa-root-domain-name. Zamiast tego można dodać wiele serwerów DNS w sieci wirtualnej, wybierając pozycję Niestandardowy serwer DNS i dodając serwery DNS.

Opcjonalnie: użyj własnej tożsamości kubelet dla klastra

Aby zapewnić dostęp klastra usługi AKS do magazynu kluczy, tożsamość kubelet klastra musi mieć dostęp do magazynu kluczy. Po utworzeniu klastra z włączoną tożsamością zarządzaną tożsamość kubelet jest tworzona automatycznie.

Możesz udzielić dostępu do magazynu kluczy dla tożsamości po utworzeniu klastra lub utworzyć własną tożsamość do użycia przed utworzeniem klastra, wykonując następujące kroki:

  1. Utwórz tożsamość kubelet przy az identity create użyciu polecenia .

    az identity create --name myIdentity --resource-group myResourceGroup

  2. Pobierz identyfikator tożsamości przy użyciu az identity list polecenia i ustaw go na zmienną o nazwie MANAGED_ID.

    MANAGED_ID=$(az identity list --query "[].id" -o tsv)

  3. Udziel tożsamości dostępu do magazynu kluczy przy użyciu az keyvault set-policy polecenia .

    az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get

Włączanie usługi GMSA w nowym klastrze usługi AKS

  1. Utwórz poświadczenia administratora do użycia podczas tworzenia klastra. Następujące polecenia wyświetlają monit o podanie nazwy użytkownika i ustaw ją na WINDOWS_USERNAME do użycia w późniejszym poleceniu.

    echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME

  2. Utwórz klaster usługi AKS przy użyciu az aks create polecenia z następującymi parametrami:

    • --enable-windows-gmsa: włącza usługę GMSA dla klastra.
    • --gmsa-dns-server: adres IP serwera DNS.
    • --gmsa-root-domain-name: nazwa domeny głównej serwera DNS.
    DNS_SERVER=<IP address of DNS server>
ROOT_DOMAIN_NAME="contoso.com"

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure \
    --load-balancer-sku standard \
    --windows-admin-username $WINDOWS_USERNAME \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME \
    --generate-ssh-keys

    Uwaga

    • Jeśli używasz niestandardowej sieci wirtualnej, musisz określić identyfikator sieci wirtualnej przy użyciu parametru vnet-subnet-id i może być konieczne dodanie parametrów docker-bridge-address, dns-service-ipi service-cidr w zależności od konfiguracji.

    • Jeśli utworzono własną tożsamość dla tożsamości kubelet, użyj parametru assign-kubelet-identity , aby określić tożsamość.

    • Po określeniu --gmsa-dns-server parametrów i --gmsa-root-domain-name do obiektu ConfigMap zostanie dodana kube-system/coredns reguła przesyłania dalej DNS. Ta reguła przekazuje żądania DNS z $ROOT_DOMAIN_NAME zasobników do .$DNS_SERVER

      $ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}

  3. Dodaj pulę węzłów systemu Windows Server przy użyciu az aks nodepool add polecenia .

    az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwin \
    --node-count 1

Włączanie usługi GMSA w istniejącym klastrze

  • Włącz usługę GMSA w istniejącym klastrze z węzłami systemu Windows Server i tożsamościami zarządzanymi włączonymi za pomocą az aks update polecenia .

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME

Udzielanie dostępu do magazynu kluczy dla tożsamości kubelet

Uwaga

Pomiń ten krok, jeśli podano własną tożsamość dla tożsamości kubelet.

  • Udziel dostępu do magazynu kluczy dla tożsamości kubelet przy az keyvault set-policy użyciu polecenia .

    MANAGED_ID=$(az aks show -g myResourceGroup -n myAKSCluster --query "identityProfile.kubeletidentity.objectId" -o tsv)
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get

Instalowanie specyfikacji cred usługi GMSA

  1. Skonfiguruj kubectl , aby nawiązać połączenie z klastrem az aks get-credentials Kubernetes przy użyciu polecenia .

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

  2. Utwórz nowy kod YAML o nazwie gmsa-spec.yaml i wklej następujący kod YAML . Upewnij się, że symbole zastępcze są zastępowane własnymi wartościami.

    apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: aks-gmsa-spec  # This name can be changed, but it will be used as a reference in the pod spec
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $NETBIOS_DOMAIN_NAME
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $DNS_DOMAIN_NAME
    HostAccountConfig:
      PluginGUID: '{CCC2A336-D7F3-4818-A213-272B7924213E}'
      PortableCcgVersion: "1"
      PluginInput: "ObjectId=$MANAGED_ID;SecretUri=$SECRET_URI"  # SECRET_URI takes the form https://$akvName.vault.azure.net/secrets/$akvSecretName
  CmsPlugins:
 - ActiveDirectory
  DomainJoinConfig:
    DnsName: $DNS_DOMAIN_NAME
    DnsTreeName: $DNS_ROOT_DOMAIN_NAME
    Guid:  $AD_DOMAIN_OBJECT_GUID
    MachineAccountName: $GMSA_ACCOUNT_USERNAME
    NetBiosName: $NETBIOS_DOMAIN_NAME
    Sid: $GMSA_SID

Uwaga

Usługa AKS uaktualniła element apiVersion GMSACredentialSpec z windows.k8s.io/v1alpha1 do windows.k8s.io/v1 w wersji 20230903.

  1. Utwórz nowy kod YAML o nazwie gmsa-role.yaml i wklej następujący kod YAML .

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aks-gmsa-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["aks-gmsa-spec"]

  2. Utwórz nowy kod YAML o nazwie gmsa-role-binding.yaml i wklej następujący kod YAML .

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-aks-gmsa-spec
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: aks-gmsa-role
  apiGroup: rbac.authorization.k8s.io

  3. Zastosuj zmiany z gmsa-spec.yaml, gmsa-role.yaml i gmsa-role-binding.yaml przy użyciu kubectl apply polecenia .

    kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml

Weryfikowanie instalacji usługi GMSA

  1. Utwórz nowy kod YAML o nazwie gmsa-demo.yaml i wklej następujący kod YAML .

    ---
kind: ConfigMap
apiVersion: v1
metadata:
  labels:
   app: gmsa-demo
  name: gmsa-demo
  namespace: default
data:
  run.ps1: |
   $ErrorActionPreference = "Stop"

   Write-Output "Configuring IIS with authentication."

   # Add required Windows features, since they are not installed by default.
   Install-WindowsFeature "Web-Windows-Auth", "Web-Asp-Net45"

   # Create simple ASP.NET page.
   New-Item -Force -ItemType Directory -Path 'C:\inetpub\wwwroot\app'
   Set-Content -Path 'C:\inetpub\wwwroot\app\default.aspx' -Value 'Authenticated as <B><%=User.Identity.Name%></B>, Type of Authentication: <B><%=User.Identity.AuthenticationType%></B>'

   # Configure IIS with authentication.
   Import-Module IISAdministration
   Start-IISCommitDelay
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/windowsAuthentication').Attributes['enabled'].value = $true
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/anonymousAuthentication').Attributes['enabled'].value = $false
   (Get-IISServerManager).Sites[0].Applications[0].VirtualDirectories[0].PhysicalPath = 'C:\inetpub\wwwroot\app'
   Stop-IISCommitDelay

   Write-Output "IIS with authentication is ready."

   C:\ServiceMonitor.exe w3svc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gmsa-demo
  template:
    metadata:
      labels:
        app: gmsa-demo
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: aks-gmsa-spec
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: IfNotPresent
        command:
         - powershell
        args:
          - -File
          - /gmsa-demo/run.ps1
        volumeMounts:
          - name: gmsa-demo
            mountPath: /gmsa-demo
      volumes:
      - configMap:
          defaultMode: 420
          name: gmsa-demo
        name: gmsa-demo
      nodeSelector:
        kubernetes.io/os: windows
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: gmsa-demo
  type: LoadBalancer

  2. Zastosuj zmiany z gmsa-demo.yaml przy użyciu kubectl apply polecenia .

    kubectl apply -f gmsa-demo.yaml

  3. Pobierz adres IP przykładowej aplikacji przy użyciu kubectl get service polecenia .

    kubectl get service gmsa-demo --watch

    EXTERNAL-IP Początkowo dla gmsa-demo usługi jest wyświetlana wartość oczekująca:

    NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
gmsa-demo          LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s

  4. EXTERNAL-IP Gdy adres zmieni się z oczekujące na rzeczywisty publiczny adres IP, użyj polecenia CTRL-C , aby zatrzymać kubectl proces oglądania.

    Następujące przykładowe dane wyjściowe przedstawiają prawidłowy publiczny adres IP przypisany do usługi:

    gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m

  5. Otwórz przeglądarkę internetową na zewnętrzny adres gmsa-demo IP usługi.

  6. Uwierzytelnij się przy użyciu $NETBIOS_DOMAIN_NAME\$AD_USERNAME hasła i i potwierdź, że zostanie wyświetlony komunikat Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

Wyłączanie usługi GMSA w istniejącym klastrze

  • Wyłącz usługę GMSA w istniejącym klastrze z węzłami systemu Windows Server za pomocą az aks update polecenia .

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-windows-gmsa

Uwaga

Możesz ponownie włączyć usługę GMSA w istniejącym klastrze przy użyciu polecenia az aks update .

Rozwiązywanie problemów

Podczas ładowania strony nie jest wyświetlany monit o uwierzytelnienie

Jeśli strona zostanie załadowana, ale nie zostanie wyświetlony monit o uwierzytelnienie, użyj kubectl logs POD_NAME polecenia , aby wyświetlić dzienniki zasobnika i sprawdzić, czy usługi IIS z uwierzytelnianiem są gotowe.

Uwaga

Kontenery systemu Windows nie będą domyślnie wyświetlać dzienników na platformie kubectl. Aby umożliwić kontenerom systemu Windows wyświetlanie dzienników, należy osadzić narzędzie Monitor dzienników w obrazie systemu Windows. Aby uzyskać więcej informacji, zobacz Narzędzia kontenera systemu Windows.

Przekroczenie limitu czasu połączenia podczas próby załadowania strony

Jeśli podczas próby załadowania strony zostanie wyświetlony limit czasu połączenia, sprawdź, czy przykładowa aplikacja jest uruchomiona przy użyciu kubectl get pods --watch polecenia . Czasami zewnętrzny adres IP przykładowej usługi App Service jest dostępny przed uruchomieniem przykładowego zasobnika aplikacji.

Nie można uruchomić zasobnika i w zdarzeniach zasobnika jest wyświetlany błąd winapi

Jeśli zasobnik nie zostanie uruchomiony po uruchomieniu kubectl get pods --watch polecenia i odczeka kilka minut, użyj kubectl describe pod POD_NAME polecenia . Jeśli w zdarzeniach zasobnika zostanie wyświetlony błąd winapi, prawdopodobnie wystąpi błąd w konfiguracji specyfikacji cred usługi GMSA. Sprawdź, czy wszystkie wartości zastępcze w pliku gmsa-spec.yaml są poprawne, uruchom kubectl apply -f gmsa-spec.yamlponownie i ponownie wdróż przykładową aplikację.

Następne kroki