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

  • Artikel

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.

Kommentar

Microsoft tillhandahåller också en specialbyggd PowerShell-modul för att konfigurera gMSA på AKS. Mer information finns i gMSA på Azure Kubernetes Service.

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 Komma 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.

Viktigt!

Du måste använda antingen Active Directory-domän Service eller lokal Active Directory. För närvarande kan du inte använda Microsoft Entra-ID för att konfigurera GMSA med ett AKS-kluster.

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-managed-identity: Aktiverar hanterad identitet för klustret.
    • --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-managed-identity \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME

    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

Kommentar

Hoppa över det här steget om du har angett din egen identitet 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

Kommentar

AKS har uppgraderat apiVersionGMSACredentialSpec från windows.k8s.io/v1alpha1 till windows.k8s.io/v1 i version v20230903.

  1. 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"]

  2. 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

  3. 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

Kommentar

Du kan återaktivera GMSA i ett befintligt kluster med hjälp av kommandot az aks update .

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.

Kommentar

Windows-containrar visar inte loggar på kubectl som standard. Om du vill att Windows-containrar ska visa loggar måste du bädda in loggövervakningsverktyget på Windows-avbildningen. Mer information finns i Windows Container Tools.

timeout för Anslut ion när du försöker 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