Aktivera grupphanterade tjänstkonton (GMSA) för dina Windows Server-noder i ditt AKS-kluster (Azure Kubernetes Service)

Grupphanterade tjänstkonton (GMSA) är ett hanterat domänkonto för flera servrar som tillhandahåller automatisk lösenordshantering, förenklad hantering av tjänstens huvudnamn (SPN) och möjligheten att delegera hantering till andra administratörer. Med Azure Kubernetes Service (AKS) kan du aktivera GMSA på dina Windows Server-noder, vilket gör att containrar som körs på Windows Server-noder kan integreras med och hanteras av GMSA.

Förutsättningar

• Kubernetes 1.19 eller senare. Information om hur du kontrollerar din version finns i Söka efter tillgängliga uppgraderingar. Information om hur du uppgraderar din version finns i Uppgradera AKS-kluster.
• Azure CLI version 2.35.0 eller senare. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.
• Hanterade identiteter aktiverade i ditt AKS-kluster.
• Behörigheter för att skapa eller uppdatera ett Azure Key Vault.
• Behörigheter för att konfigurera GMSA på Active Directory-domän Service eller lokal Active Directory.
• Domänkontrollanten måste ha Active Directory Web Services aktiverat och måste kunna nås på port 9389 av AKS-klustret.

Konfigurera GMSA på Active Directory-domänkontrollant

Om du vill använda GMSA med AKS behöver du en standardautentiseringsuppgift för domänanvändare för att få åtkomst till de GMSA-autentiseringsuppgifter som konfigurerats på domänkontrollanten. Information om hur du konfigurerar GMSA på domänkontrollanten finns i Kom igång med grupphanterade tjänstkonton. För standardautentiseringsuppgifter för domänanvändare kan du använda en befintlig användare eller skapa en ny, så länge den har åtkomst till GMSA-autentiseringsuppgifterna.

Lagra standardautentiseringsuppgifterna för domänanvändare i Azure Key Vault

AKS-klustret använder standardautentiseringsuppgifterna för domänanvändare för att komma åt GMSA-autentiseringsuppgifterna från domänkontrollanten. Om du vill ge säker åtkomst till dessa autentiseringsuppgifter för AKS-klustret bör du lagra dem i Azure Key Vault.

1. Om du inte redan har ett Azure-nyckelvalv skapar du ett med kommandot az keyvault create .

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

2. Lagra standardautentiseringsuppgifterna för domänanvändare som en hemlighet i nyckelvalvet med hjälp av az keyvault secret set kommandot . I följande exempel lagras domänanvändarens autentiseringsuppgifter med nyckeln GMSADomainUserCred i nyckelvalvet myGMSAVault .

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

   Kommentar

   Se till att använda det fullständigt kvalificerade domännamnet för domänen.

Valfritt: Använd ett anpassat virtuellt nätverk med anpassad DNS

Du måste konfigurera domänkontrollanten via DNS så att den kan nås av AKS-klustret. Du kan konfigurera nätverket och DNS utanför AKS-klustret så att klustret får åtkomst till domänkontrollanten. Du kan också använda Azure CNI för att konfigurera ett anpassat VNet med en anpassad DNS i AKS-klustret för att ge åtkomst till domänkontrollanten. Mer information finns i Konfigurera Azure CNI-nätverk i Azure Kubernetes Service (AKS).

Valfritt: Konfigurera mer än en DNS-server

Om du vill konfigurera mer än en DNS-server för Windows GMSA i AKS-klustret ska du inte ange --gmsa-dns-servereller v--gmsa-root-domain-name. I stället kan du lägga till flera DNS-servrar i det virtuella nätverket genom att välja Anpassad DNS och lägga till DNS-servrarna.

Valfritt: Använd din egen kubelet-identitet för klustret

För att ge AKS-klustret åtkomst till ditt nyckelvalv behöver klustrets kubelet-identitet åtkomst till ditt nyckelvalv. När du skapar ett kluster med hanterad identitet aktiverad skapas en kubelet-identitet automatiskt som standard.

Du kan antingen bevilja åtkomst till ditt nyckelvalv för identiteten när klustret har skapats eller skapa en egen identitet som ska användas innan klustret skapas med hjälp av följande steg:

1. Skapa en kubelet-identitet med kommandot az identity create .

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

2. Hämta identitetens ID med hjälp av az identity list kommandot och ange det till en variabel med namnet MANAGED_ID.

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

3. Ge identiteten åtkomst till ditt nyckelvalv med hjälp av az keyvault set-policy kommandot .

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

Aktivera GMSA i ett nytt AKS-kluster

1. Skapa administratörsautentiseringsuppgifter som ska användas när klustret skapas. Följande kommandon uppmanar dig att ange ett användarnamn och ange det till WINDOWS_USERNAME för användning i ett senare kommando.

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

2. Skapa ett AKS-kluster med kommandot az aks create med följande parametrar:

   • --enable-windows-gmsa: Aktiverar GMSA för klustret.
   • --gmsa-dns-server: DNS-serverns IP-adress.
   • --gmsa-root-domain-name: DNS-serverns rotdomännamn.

   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
   

   Kommentar

   • Om du använder ett anpassat virtuellt nätverk måste du ange det virtuella nätverks-ID:t med hjälp av parametern vnet-subnet-id och du kan också behöva lägga till parametrarna docker-bridge-address, dns-service-ipoch service-cidr beroende på din konfiguration.

   • Om du har skapat din egen identitet för kubelet-identiteten använder du parametern assign-kubelet-identity för att ange din identitet.

   • När du anger parametrarna --gmsa-dns-server och --gmsa-root-domain-name läggs en DNS-vidarebefordranregel till i kube-system/coredns ConfigMap. Den här regeln vidarebefordrar DNS-begäranden från $ROOT_DOMAIN_NAME poddarna till $DNS_SERVER.

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

3. Lägg till en Windows Server-nodpool med kommandot az aks nodepool add .

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

Aktivera GMSA i ett befintligt kluster

• Aktivera GMSA i ett befintligt kluster med Windows Server-noder och hanterade identiteter aktiverade med kommandot az aks update .

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

Bevilja åtkomst till ditt nyckelvalv för kubelet-identiteten

• Bevilja åtkomst till ditt nyckelvalv för kubelet-identiteten az keyvault set-policy med hjälp av kommandot .

  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
  

Installera GMSA cred spec

1. Konfigurera kubectl för att ansluta till kubernetes-klustret med hjälp av az aks get-credentials kommandot .

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

2. Skapa en ny YAML med namnet gmsa-spec.yaml och klistra in följande YAML. Se till att du ersätter platshållarna med dina egna värden.

   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
   

3. Skapa en ny YAML med namnet gmsa-role.yaml och klistra in följande 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"]
   

4. Skapa en ny YAML med namnet gmsa-role-binding.yaml och klistra in följande 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
   

5. Använd ändringarna från gmsa-spec.yaml, gmsa-role.yaml och gmsa-role-binding.yaml med kommandot kubectl apply .

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

Verifiera GMSA-installationen

1. Skapa en ny YAML med namnet gmsa-demo.yaml och klistra in följande 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. Använd ändringarna från gmsa-demo.yaml med kommandot kubectl apply .

   kubectl apply -f gmsa-demo.yaml
   

3. Hämta IP-adressen för exempelprogrammet med kommandot kubectl get service .

   kubectl get service gmsa-demo --watch
   

   EXTERNAL-IP Till en början visas för gmsa-demo tjänsten som väntande:

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

4. EXTERNAL-IP När adressen ändras från väntande till en faktisk offentlig IP-adress använder du CTRL-C för att stoppa kubectl bevakningsprocessen.

   Följande exempelutdata visar en giltig offentlig IP-adress som har tilldelats tjänsten:

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

5. Öppna en webbläsare till tjänstens gmsa-demo externa IP-adress.

6. Autentisera $NETBIOS_DOMAIN_NAME\$AD_USERNAME med lösenordet och och bekräfta att du ser Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

Inaktivera GMSA i ett befintligt kluster

• Inaktivera GMSA i ett befintligt kluster med Windows Server-noder med kommandot az aks update .

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

Felsökning

Ingen autentisering tillfrågas när sidan läses in

Om sidan läses in, men du inte uppmanas att autentisera kubectl logs POD_NAME , använder du kommandot för att visa loggarna för din podd och kontrollera att IIS med autentisering är klar.

Tidsgräns för anslutning vid försök att läsa in sidan

Om du får en tidsgräns för anslutningen när du försöker läsa in sidan kontrollerar du att exempelappen körs med kommandot kubectl get pods --watch . Ibland är den externa IP-adressen för exempelapptjänsten tillgänglig innan exempelapppodden körs.

Podden startar inte och ett winapi-fel visas i poddhändelserna

Om podden inte startar efter att kubectl get pods --watch ha kört kommandot och väntat i flera minuter använder du kubectl describe pod POD_NAME kommandot . Om du ser ett winapi-fel i poddhändelserna är det troligtvis ett fel i konfigurationen av gmsa-cred-specifikationen. Kontrollera att alla ersättningsvärden i gmsa-spec.yaml är korrekta, kör kubectl apply -f gmsa-spec.yamlom och distribuera om exempelprogrammet.

Nästa steg

Mer information finns i Överväganden för Windows-containrar med Azure Kubernetes Service (AKS).