Sdílet prostřednictvím

Povolení skupinových účtů spravované služby (GMSA) pro uzly Windows Serveru v clusteru Azure Kubernetes Service (AKS)

  • Článek

Účty spravované služby (GMSA) jsou spravovaným účtem domény pro více serverů, které poskytují automatickou správu hesel, zjednodušenou správu hlavního názvu služby (SPN) a schopnost delegovat správu jiným správcům. Pomocí služby Azure Kubernetes Service (AKS) můžete povolit GMSA na uzlech Windows Serveru, což umožňuje integraci kontejnerů spuštěných na uzlech Windows Serveru a jejich správu pomocí GMSA.

Požadavky

  • Kubernetes 1.19 nebo novější Pokud chcete zkontrolovat verzi, přečtěte si téma Kontrola dostupných upgradů. Pokud chcete upgradovat verzi, přečtěte si téma Upgrade clusteru AKS.
  • Azure CLI verze 2.35.0 nebo novější Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.
  • Spravované identity povolené v clusteru AKS
  • Oprávnění k vytvoření nebo aktualizaci služby Azure Key Vault
  • Oprávnění ke konfiguraci GMSA ve službě Doména služby Active Directory Service nebo místní Active Directory
  • Řadič domény musí mít povolenou službu Active Directory Web Services a musí být dostupný na portu 9389 clusterem AKS.

Poznámka:

Microsoft také poskytuje účelový modul PowerShellu pro konfiguraci gMSA v AKS. Další informace najdete v tématu gMSA ve službě Azure Kubernetes Service.

Konfigurace GMSA na řadiči domény služby Active Directory

Pokud chcete používat GMSA s AKS, potřebujete standardní přihlašovací údaje uživatele domény pro přístup k přihlašovacím údajům GMSA nakonfigurovaným na řadiči domény. Informace o konfiguraci GMSA na řadiči domény najdete v tématu Začínáme se skupinami účtů spravované služby. Pro přihlašovací údaje standardního uživatele domény můžete použít existujícího uživatele nebo vytvořit nový, pokud má přístup k přihlašovacím údajům GMSA.

Důležité

Musíte použít službu Doména služby Active Directory nebo místní Active Directory. V tuto chvíli nemůžete použít ID Microsoft Entra ke konfiguraci GMSA s clusterem AKS.

Uložení přihlašovacích údajů standardního uživatele domény ve službě Azure Key Vault

Cluster AKS používá standardní přihlašovací údaje uživatele domény pro přístup k přihlašovacím údajům GMSA z řadiče domény. Pokud chcete zajistit zabezpečený přístup k těmto přihlašovacím údajům pro cluster AKS, měli byste je uložit ve službě Azure Key Vault.

  1. Pokud ještě nemáte trezor klíčů Azure, vytvořte ho az keyvault create pomocí příkazu.

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

  2. Pomocí příkazu uložte přihlašovací údaje standardního uživatele domény jako tajný klíč do trezoru az keyvault secret set klíčů. Následující příklad ukládá přihlašovací údaje uživatele domény s klíčem GMSADomainUserCred v trezoru klíčů myGMSAVault .

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

    Poznámka:

    Ujistěte se, že pro doménu používáte plně kvalifikovaný název domény.

Volitelné: Použití vlastní virtuální sítě s vlastním DNS

Musíte nakonfigurovat řadič domény prostřednictvím DNS, aby byl dostupný clusterem AKS. Síť a DNS můžete nakonfigurovat mimo cluster AKS, aby mohl váš cluster přistupovat k řadiči domény. Alternativně můžete pomocí Azure CNI nakonfigurovat vlastní virtuální síť s vlastním DNS ve vašem clusteru AKS a poskytnout tak přístup k řadiči domény. Další informace najdete v tématu Konfigurace sítí Azure CNI ve službě Azure Kubernetes Service (AKS).

Volitelné: Konfigurace více než jednoho serveru DNS

Pokud chcete v clusteru AKS nakonfigurovat více než jeden server DNS pro Windows GMSA, nezadávejte --gmsa-dns-serverani v--gmsa-root-domain-name. Místo toho můžete do virtuální sítě přidat více serverů DNS tak, že vyberete Vlastní DNS a přidáte servery DNS.

Volitelné: Použití vlastní identity kubeletu pro cluster

K zajištění přístupu clusteru AKS k trezoru klíčů potřebuje identita kubeletu clusteru přístup k vašemu trezoru klíčů. Když vytvoříte cluster s povolenou spravovanou identitou, automaticky se vytvoří identita kubeletu.

Po vytvoření clusteru můžete buď udělit přístup k trezoru klíčů identitě, nebo vytvořit vlastní identitu, která se má použít před vytvořením clusteru, pomocí následujících kroků:

  1. Pomocí příkazu vytvořte identitu kubeletu az identity create .

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

  2. Získejte ID identity pomocí az identity list příkazu a nastavte ho na proměnnou s názvem MANAGED_ID.

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

  3. Pomocí příkazu udělte identitě přístup k trezoru az keyvault set-policy klíčů.

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

Povolení GMSA v novém clusteru AKS

  1. Vytvořte přihlašovací údaje správce, které se mají použít při vytváření clusteru. Následující příkazy zobrazí výzvu k zadání uživatelského jména a nastaví ho na WINDOWS_USERNAME pro pozdější použití.

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

  2. Vytvořte cluster AKS pomocí az aks create příkazu s následujícími parametry:

    • --enable-windows-gmsa: Povolí GMSA pro cluster.
    • --gmsa-dns-server: IP adresa serveru DNS.
    • --gmsa-root-domain-name: Název kořenové domény serveru 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

    Poznámka:

    • Pokud používáte vlastní virtuální síť, musíte pomocí parametru vnet-subnet-id zadat ID virtuální sítě a v závislosti na konfiguraci možná budete muset přidat docker-bridge-addresstaké parametr , dns-service-ipa service-cidr parametry.

    • Pokud jste pro identitu kubelet vytvořili vlastní identitu, zadejte svoji identitu pomocí parametru assign-kubelet-identity .

    • Při zadávání --gmsa-dns-server parametrů a --gmsa-root-domain-name parametrů se do objektu kube-system/coredns ConfigMap přidá pravidlo předávání DNS. Toto pravidlo předá požadavky DNS z $ROOT_DOMAIN_NAME podů na $DNS_SERVER.

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

  3. Přidejte fond uzlů Windows Serveru pomocí az aks nodepool add příkazu.

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

Povolení GMSA v existujícím clusteru

  • Povolte GMSA v existujícím clusteru s uzly Windows Serveru a spravovanými identitami povolenými pomocí az aks update příkazu.

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

Udělení přístupu k trezoru klíčů pro identitu kubeletu

Poznámka:

Tento krok přeskočte, pokud jste pro identitu kubelet zadali vlastní identitu.

  • Pomocí příkazu udělte přístup k trezoru klíčů pro identitu kubeletu az keyvault set-policy .

    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

Instalace specifikace CRSA pro GMSA

  1. Pomocí příkazu nakonfigurujte kubectl připojení ke clusteru az aks get-credentials Kubernetes.

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

  2. Vytvořte nový YAML s názvem gmsa-spec.yaml a vložte následující YAML. Nezapomeňte zástupné symboly nahradit vlastními hodnotami.

    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

Poznámka:

Služba AKS upgradovala apiVersion z verze v20230903 na GMSACredentialSpecwindows.k8s.io/v1alpha1windows.k8s.io/v1 verzi 20230903.

  1. Vytvořte nový YAML s názvem gmsa-role.yaml a vložte následující 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. Vytvořte nový YAML s názvem gmsa-role-binding.yaml a vložte ho do následujícího 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. Pomocí příkazu použijte změny z gmsa-spec.yaml, gmsa-role.yaml a gmsa-role-binding.yamlkubectl apply. 

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

Ověření instalace GMSA

  1. Vytvořte nový YAML s názvem gmsa-demo.yaml a vložte ho do následujícího 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. Pomocí příkazu použijte změny z gmsa-demo.yamlkubectl apply.

    kubectl apply -f gmsa-demo.yaml

  3. Pomocí příkazu získejte IP adresu ukázkové aplikace kubectl get service .

    kubectl get service gmsa-demo --watch

    Zpočátku se EXTERNAL-IPgmsa-demo pro službu zobrazuje jako čekající:

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

  4. Když se EXTERNAL-IP adresa změní z čekání na skutečnou kubectl veřejnou IP adresu, použijte CTRL-C k zastavení procesu sledování.

    Následující příklad výstupu ukazuje platnou veřejnou IP adresu přiřazenou službě:

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

  5. Otevřete webový prohlížeč na externí IP adresu gmsa-demo služby.

  6. Ověřte se $NETBIOS_DOMAIN_NAME\$AD_USERNAME pomocí hesla a potvrďte, že se zobrazí Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

Zakázání GMSA v existujícím clusteru

  • Pomocí příkazu zakažte GMSA v existujícím clusteru s uzly az aks update Windows Serveru.

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

Poznámka:

Ke opětovnému povolení GMSA v existujícím clusteru můžete použít příkaz az aks update .

Řešení problému

Při načítání stránky se nezobrazí výzva k žádnému ověření.

Pokud se stránka načte, ale nezobrazí se výzva k ověření, pomocí kubectl logs POD_NAME příkazu zobrazte protokoly podu a ověřte, že je služba IIS s ověřováním připravená.

Poznámka:

Kontejnery Windows ve výchozím nastavení nezobrazují protokoly v kubectl. Pokud chcete, aby kontejnery Windows zobrazovaly protokoly, musíte do image Windows vložit nástroj Log Monitor. Další informace naleznete v tématu Nástroje kontejneru systému Windows.

Vypršení časového limitu připojení při pokusu o načtení stránky

Pokud při pokusu o načtení stránky dojde k vypršení časového limitu připojení, pomocí příkazu ověřte, že je ukázková aplikace spuštěná kubectl get pods --watch . Někdy je externí IP adresa ukázkové služby App Service k dispozici před spuštěním podu ukázkové aplikace.

Pod se nepodaří spustit a v událostech podu se zobrazí chyba winapi

Pokud se pod po spuštění kubectl get pods --watch příkazu nespustí a čeká několik minut, použijte tento kubectl describe pod POD_NAME příkaz. Pokud se v událostech podu zobrazí chyba winapi, pravděpodobně se jedná o chybu v konfiguraci specifikace CRSA GMSA. Ověřte správnost všech náhradních hodnot v gmsa-spec.yaml , opětovné spuštění kubectl apply -f gmsa-spec.yamla opětovné nasazení ukázkové aplikace.

Další kroky