Groep beheerde serviceaccounts (GMSA) inschakelen voor uw Windows Server-knooppunten in uw AKS-cluster (Azure Kubernetes Service)

Artikel
10/15/2024

Group Managed Service Accounts (GMSA) is een beheerd domeinaccount voor meerdere servers die automatisch wachtwoordbeheer, vereenvoudigd SPN-beheer (Service Principal Name) en de mogelijkheid om beheer te delegeren aan andere beheerders. Met Azure Kubernetes Service (AKS) kunt u GMSA inschakelen op uw Windows Server-knooppunten, zodat containers die op Windows Server-knooppunten worden uitgevoerd, kunnen worden geïntegreerd en beheerd door GMSA.

Vereisten

Kubernetes 1.19 of hoger. Zie Controleren op beschikbare upgrades om uw versie te controleren. Zie AKS-cluster upgraden om uw versie bij te werken.
Azure CLI versie 2.35.0 of hoger. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.
Beheerde identiteiten die zijn ingeschakeld op uw AKS-cluster.
Machtigingen voor het maken of bijwerken van een Azure Key Vault.
Machtigingen voor het configureren van GMSA in Active Directory-domein Service of on-premises Active Directory.
De domeincontroller moet Active Directory Web Services hebben ingeschakeld en moet bereikbaar zijn op poort 9389 door het AKS-cluster.

Notitie

Microsoft biedt ook een speciaal gebouwde PowerShell-module voor het configureren van gMSA op AKS. Zie gMSA in Azure Kubernetes Service voor meer informatie.

GMSA configureren op Active Directory-domeincontroller

Als u GMSA wilt gebruiken met AKS, hebt u een standaardreferentie voor domeingebruikers nodig om toegang te krijgen tot de GMSA-referentie die is geconfigureerd op uw domeincontroller. Zie Aan de slag met door groep beheerde serviceaccounts om GMSA op uw domeincontroller te configureren. Voor de standaardreferentie voor domeingebruikers kunt u een bestaande gebruiker gebruiken of een nieuwe maken, zolang deze toegang heeft tot de GMSA-referentie.

Belangrijk

U moet Active Directory-domein Service of on-premises Active Directory gebruiken. Op dit moment kunt u microsoft Entra-id niet gebruiken om GMSA te configureren met een AKS-cluster.

De standaardreferenties van domeingebruikers opslaan in Azure Key Vault

Uw AKS-cluster gebruikt de standaardreferenties voor domeingebruikers om toegang te krijgen tot de GMSA-referenties van de domeincontroller. Als u beveiligde toegang tot deze referenties voor het AKS-cluster wilt bieden, moet u deze opslaan in Azure Key Vault.

Als u nog geen Azure-sleutelkluis hebt, maakt u er een met behulp van de az keyvault create opdracht.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
Sla de standaardreferenties voor domeingebruikers op als een geheim in uw sleutelkluis met behulp van de az keyvault secret set opdracht. In het volgende voorbeeld worden de referenties van de domeingebruiker opgeslagen met de sleutel GMSADomainUserCred in de sleutelkluis myGMSAVault .
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Notitie

Zorg ervoor dat u de Fully Qualified Domain Name voor het domein gebruikt.

Optioneel: Een aangepast VNet gebruiken met aangepaste DNS

U moet uw domeincontroller configureren via DNS, zodat deze bereikbaar is via het AKS-cluster. U kunt uw netwerk en DNS buiten uw AKS-cluster configureren om uw cluster toegang te geven tot de domeincontroller. U kunt ook Azure CNI gebruiken om een aangepast VNet te configureren met een aangepastE DNS op uw AKS-cluster om toegang te bieden tot uw domeincontroller. Zie Azure CNI-netwerken configureren in Azure Kubernetes Service (AKS) voor meer informatie.

Optioneel: meer dan één DNS-server configureren

Als u meer dan één DNS-server wilt configureren voor Windows GMSA in uw AKS-cluster, geeft u deze niet op --gmsa-dns-serverof v--gmsa-root-domain-name. In plaats daarvan kunt u meerdere DNS-servers toevoegen in het VNet door Aangepaste DNS te selecteren en de DNS-servers toe te voegen.

Optioneel: Uw eigen kubelet-identiteit gebruiken voor uw cluster

Als u de AKS-clustertoegang tot uw sleutelkluis wilt bieden, moet de kubelet-identiteit van het cluster toegang hebben tot uw sleutelkluis. Wanneer u een cluster maakt waarvoor beheerde identiteit is ingeschakeld, wordt standaard automatisch een kubelet-identiteit gemaakt.

U kunt na het maken van een cluster toegang verlenen tot uw sleutelkluis voor de identiteit of uw eigen identiteit maken voordat het cluster wordt gemaakt met behulp van de volgende stappen:

Maak een kubelet-identiteit met behulp van de az identity create opdracht.
```
az identity create --name myIdentity --resource-group myResourceGroup
```
Haal de id van de identiteit op met behulp van de az identity list opdracht en stel deze in op een variabele met de naam MANAGED_ID.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```
Verdeel de identiteit toegang tot uw sleutelkluis met behulp van de az keyvault set-policy opdracht.
```
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
```

GMSA inschakelen op een nieuw AKS-cluster

Maak beheerdersreferenties die u wilt gebruiken tijdens het maken van het cluster. Met de volgende opdrachten wordt u om een gebruikersnaam gevraagd en ingesteld op WINDOWS_USERNAME voor gebruik in een latere opdracht.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Maak een AKS-cluster met behulp van de az aks create opdracht met de volgende parameters:
- --enable-windows-gmsa: hiermee schakelt u GMSA in voor het cluster.
- --gmsa-dns-server: het IP-adres van de DNS-server.
- --gmsa-root-domain-name: de hoofddomeinnaam van de DNS-server.
```
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
```
Notitie
- Als u een aangepast VNet gebruikt, moet u de VNet-id opgeven met behulp van de vnet-subnet-id parameter en moet u mogelijk ook de docker-bridge-address, dns-service-ipen service-cidr parameters toevoegen, afhankelijk van uw configuratie.
- Als u uw eigen identiteit voor de kubelet-identiteit hebt gemaakt, gebruikt u de assign-kubelet-identity parameter om uw identiteit op te geven.
- Wanneer u de --gmsa-dns-server en --gmsa-root-domain-name parameters opgeeft, wordt er een DNS-doorstuurregel toegevoegd aan de kube-system/coredns ConfigMap. Met deze regel worden de DNS-aanvragen van $ROOT_DOMAIN_NAME de pods doorgestuurd naar de $DNS_SERVER.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Voeg een Windows Server-knooppuntgroep toe met behulp van de az aks nodepool add opdracht.

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

GMSA inschakelen op bestaand cluster

Schakel GMSA in op een bestaand cluster met Windows Server-knooppunten en beheerde identiteiten ingeschakeld met behulp van de az aks update opdracht.

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

Toegang verlenen tot uw sleutelkluis voor de kubelet-identiteit

Notitie

Sla deze stap over als u uw eigen identiteit hebt opgegeven voor de kubelet-identiteit.

Ververleent toegang tot uw sleutelkluis voor de kubelet-identiteit met behulp van de az keyvault set-policy opdracht.

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

GMSA cred spec installeren

Configureer kubectl deze om verbinding te maken met uw Kubernetes-cluster met behulp van de az aks get-credentials opdracht.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Maak een nieuwe YAML met de naam gmsa-spec.yaml en plak deze in de volgende YAML. Zorg ervoor dat u de tijdelijke aanduidingen vervangt door uw eigen waarden.

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

Notitie

AKS heeft een apiVersion upgrade uitgevoerd van windows.k8s.io/v1alpha1 GMSACredentialSpec naar windows.k8s.io/v1 versie v20230903.

Maak een nieuwe YAML met de naam gmsa-role.yaml en plak deze in de volgende 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"]

Maak een nieuwe YAML met de naam gmsa-role-binding.yaml en plak deze in de volgende 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

Pas de wijzigingen toe van gmsa-spec.yaml, gmsa-role.yaml en gmsa-role-binding.yaml met behulp van de kubectl apply opdracht.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

GMSA-installatie controleren

Maak een nieuwe YAML met de naam gmsa-demo.yaml en plak de volgende 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

Pas de wijzigingen van gmsa-demo.yaml toe met behulp van de kubectl apply opdracht.
```
kubectl apply -f gmsa-demo.yaml
```

Haal het IP-adres van de voorbeeldtoepassing op met behulp van de kubectl get service opdracht.

kubectl get service gmsa-demo --watch

In eerste instantie wordt het EXTERNAL-IP voor de gmsa-demo service weergegeven als in behandeling:

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

Wanneer het EXTERNAL-IP adres in behandeling is in een echt openbaar IP-adres, gebruikt CTRL-C u dit om het kubectl controleproces te stoppen.

In de volgende voorbeelduitvoer ziet u een geldig openbaar IP-adres dat aan de service is toegewezen:
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Open een webbrowser naar het externe IP-adres van de gmsa-demo service.
Verifieer met het $NETBIOS_DOMAIN_NAME\$AD_USERNAME en wachtwoord en bevestig dat u het ziet Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

GMSA uitschakelen op een bestaand cluster

Schakel GMSA uit op een bestaand cluster met Windows Server-knooppunten met behulp van de az aks update opdracht.

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

Notitie

U kunt GMSA opnieuw inschakelen op een bestaand cluster met behulp van de opdracht az aks update .

Probleemoplossing

Als de pagina wordt geladen, maar u niet wordt gevraagd om te verifiëren, gebruikt u de kubectl logs POD_NAME opdracht om de logboeken van uw pod weer te geven en te controleren of IIS met verificatie gereed is.

Notitie

In Windows-containers worden standaard geen logboeken op kubectl weergegeven. Als u wilt dat Windows-containers logboeken kunnen weergeven, moet u het hulpprogramma Logboekcontrole insluiten in uw Windows-installatiekopieën. Zie Windows Container Tools voor meer informatie.

Time-out voor verbinding bij het laden van de pagina

Als u een verbindingstime-out ontvangt bij het laden van de pagina, controleert u of de voorbeeld-app wordt uitgevoerd met behulp van de kubectl get pods --watch opdracht. Soms is het externe IP-adres voor de voorbeeld-app-service beschikbaar voordat de pod van de voorbeeld-app wordt uitgevoerd.

Pod kan niet worden gestart en er wordt een winapi-fout weergegeven in de podgebeurtenissen

Als uw pod niet start nadat de kubectl get pods --watch opdracht is uitgevoerd en enkele minuten wacht, gebruikt u de kubectl describe pod POD_NAME opdracht. Als u een winapi-fout in de podgebeurtenissen ziet, is dit waarschijnlijk een fout in de configuratie van de GMSA-cred spec. Controleer of alle vervangende waarden in gmsa-spec.yaml juist zijn, voer deze opnieuw uit kubectl apply -f gmsa-spec.yamlen implementeer de voorbeeldtoepassing opnieuw.

Volgende stappen

Zie Overwegingen voor Windows-containers met Azure Kubernetes Service (AKS) voor meer informatie.

Delen via

Groep beheerde serviceaccounts (GMSA) inschakelen voor uw Windows Server-knooppunten in uw AKS-cluster (Azure Kubernetes Service)

Vereisten

GMSA configureren op Active Directory-domeincontroller

De standaardreferenties van domeingebruikers opslaan in Azure Key Vault

Optioneel: Een aangepast VNet gebruiken met aangepaste DNS

Optioneel: meer dan één DNS-server configureren

Optioneel: Uw eigen kubelet-identiteit gebruiken voor uw cluster

GMSA inschakelen op een nieuw AKS-cluster

GMSA inschakelen op bestaand cluster

Toegang verlenen tot uw sleutelkluis voor de kubelet-identiteit

GMSA cred spec installeren

GMSA-installatie controleren

GMSA uitschakelen op een bestaand cluster

Probleemoplossing

Er wordt geen verificatie gevraagd bij het laden van de pagina

Time-out voor verbinding bij het laden van de pagina

Pod kan niet worden gestart en er wordt een winapi-fout weergegeven in de podgebeurtenissen

Volgende stappen

Aanvullende resources