Csoport által felügyelt szolgáltatásfiókok (GMSA) engedélyezése a Windows Server-csomópontokhoz az Azure Kubernetes Service -fürtön

Cikk
10/24/2023

A csoportos felügyelt szolgáltatásfiókok (GMSA) egy felügyelt tartományi fiók több kiszolgálóhoz, amelyek automatikus jelszókezelést, egyszerűsített egyszerű szolgáltatásnevet (SPN) biztosítanak, valamint lehetővé teszi a felügyelet más rendszergazdáknak való delegálását. Az Azure Kubernetes Service (AKS) segítségével engedélyezheti a GMSA-t a Windows Server-csomópontokon, így a Windows Server-csomópontokon futó tárolók integrálhatók a GMSA-val, és kezelhetik azt.

Előfeltételek

Kubernetes 1.19 vagy újabb. A verzió ellenőrzéséhez tekintse meg az elérhető frissítéseket. A verzió frissítéséhez tekintse meg az AKS-fürt frissítését.
Az Azure CLI 2.35.0-s vagy újabb verziója. A verzió azonosításához futtassa a következőt: az --version. Ha telepíteni vagy frissíteni szeretne: Az Azure CLI telepítése.
Az AKS-fürtön engedélyezett felügyelt identitások .
Az Azure Key Vault létrehozásához vagy frissítéséhez szükséges engedélyek.
A GMSA konfigurálására vonatkozó engedélyek Active Directory-tartomány szolgáltatáson vagy helyi Active Directory.
A tartományvezérlőnek engedélyeznie kell az Active Directory Web Services szolgáltatást, és az AKS-fürtnek el kell érnie a 9389-s porton.

Megjegyzés:

A Microsoft egy célként létrehozott PowerShell-modult is biztosít a gMSA AKS-en való konfigurálásához. További információ: gMSA az Azure Kubernetes Service-ben.

GMSA konfigurálása Az Active Directory tartományvezérlőn

A GMSA AKS-sel való használatához szabványos tartományfelhasználói hitelesítő adatokra van szükség a tartományvezérlőn konfigurált GMSA-hitelesítő adatok eléréséhez. A GMSA tartományvezérlőn való konfigurálásához tekintse meg a csoport által felügyelt szolgáltatásfiókok használatának első lépéseit. A szabványos tartományfelhasználói hitelesítő adatokhoz használhat egy meglévő felhasználót, vagy létrehozhat egy újat, feltéve, hogy hozzáfér a GMSA hitelesítő adataihoz.

Fontos

Active Directory-tartomány szolgáltatást vagy helyi Active Directory kell használnia. Jelenleg nem használhatja a Microsoft Entra ID-t a GMSA AKS-fürttel való konfigurálásához.

A standard tartományi felhasználói hitelesítő adatok tárolása az Azure Key Vaultban

Az AKS-fürt a szabványos tartományi felhasználói hitelesítő adatokkal fér hozzá a GMSA hitelesítő adataihoz a tartományvezérlőről. Az AKS-fürt hitelesítő adataihoz való biztonságos hozzáférés biztosításához az Azure Key Vaultban kell tárolnia őket.

Ha még nem rendelkezik Azure Key Vaulttal, hozzon létre egyet a az keyvault create paranccsal.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
A parancs használatával titkos kódként tárolja a standard tartományfelhasználói hitelesítő adatokat a az keyvault secret set kulcstartóban. Az alábbi példa a tartományfelhasználó hitelesítő adatait a GMSADomainUserCred kulccsal tárolja a myGMSAVault kulcstartóban.
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Megjegyzés:

Ügyeljen arra, hogy a tartomány teljes tartománynevét használja.

Nem kötelező: Egyéni virtuális hálózat használata egyéni DNS-sel

Konfigurálnia kell a tartományvezérlőt DNS-sel, hogy az elérhető legyen az AKS-fürt számára. Konfigurálhatja a hálózatot és a DNS-t az AKS-fürtön kívül, hogy a fürt hozzáférhessen a tartományvezérlőhöz. Másik lehetőségként az Azure CNI használatával egyéni virtuális hálózatot konfigurálhat egyéni DNS-sel az AKS-fürtön, hogy hozzáférést biztosítson a tartományvezérlőhöz. További információ: Azure CNI-hálózatkezelés konfigurálása az Azure Kubernetes Service-ben (AKS).

Nem kötelező: Több DNS-kiszolgáló konfigurálása

Ha egynél több DNS-kiszolgálót szeretne konfigurálni a Windows GMSA-hoz az AKS-fürtben, ne adja meg --gmsa-dns-servervagy v--gmsa-root-domain-namene. Ehelyett több DNS-kiszolgálót is hozzáadhat a virtuális hálózathoz az egyéni DNS kiválasztásával és a DNS-kiszolgálók hozzáadásával.

Nem kötelező: Saját kubelet-identitás használata a fürthöz

Ahhoz, hogy az AKS-fürt hozzáférjen a kulcstartóhoz, a fürt kubelet-identitásának hozzá kell férnie a kulcstartóhoz. Ha olyan fürtöt hoz létre, amelyen engedélyezve van a felügyelt identitás, a kubelet-identitás alapértelmezés szerint automatikusan létrejön.

A fürt létrehozása után hozzáférést adhat a kulcstartóhoz az identitáshoz, vagy létrehozhat saját identitást a fürt létrehozása előtt a következő lépések végrehajtásával:

Hozzon létre egy kubelet-identitást a az identity create paranccsal.

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

Kérje le az identitás azonosítóját a az identity list paranccsal, és állítsa be egy MANAGED_ID nevű változóra.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```
Adjon hozzáférést az identitásnak a kulcstartóhoz a az keyvault set-policy parancs használatával.
```
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
```

GMSA engedélyezése új AKS-fürtön

A fürt létrehozása során használandó rendszergazdai hitelesítő adatok létrehozása. Az alábbi parancsok egy felhasználónevet kérnek, és beállítják WINDOWS_UStandard kiadás RNAME értékre egy későbbi parancsban való használatra.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Hozzon létre egy AKS-fürtöt a az aks create következő paraméterekkel rendelkező paranccsal:
- --enable-managed-identity: Engedélyezi a fürt felügyelt identitását.
- --enable-windows-gmsa: Engedélyezi a GMSA-t a fürthöz.
- --gmsa-dns-server: A DNS-kiszolgáló IP-címe.
- --gmsa-root-domain-name: A DNS-kiszolgáló gyökértartományneve.
```
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
```
Megjegyzés:
- Ha egyéni virtuális hálózatot használ, meg kell adnia a virtuális hálózat azonosítóját a vnet-subnet-id paraméterrel, és előfordulhat, hogy a konfigurációtól függően hozzá kell adnia a docker-bridge-address, dns-service-ipés service-cidr a paramétereket is.
- Ha saját identitást hozott létre a kubelet-identitáshoz, használja a assign-kubelet-identity paramétert az identitás megadásához.
- A paraméterek és --gmsa-root-domain-name a --gmsa-dns-server paraméterek megadásakor a rendszer hozzáad egy DNS-továbbítási szabályt a kube-system/coredns konfigurációtérképhez. Ez a szabály továbbítja a podok DNS-kéréseit $ROOT_DOMAIN_NAME a $DNS_SERVER.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Adjon hozzá egy Windows Server-csomópontkészletet a az aks nodepool add paranccsal.

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

GMSA engedélyezése meglévő fürtön

Engedélyezze a GMSA-t egy meglévő fürtön, amelyen engedélyezve van a Windows Server-csomópontok és a felügyelt identitások a az aks update parancs használatával.

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

Hozzáférés biztosítása a kubelet-identitás kulcstartójához

Megjegyzés:

Hagyja ki ezt a lépést, ha saját identitást adott meg a kubelet-identitáshoz.

Adjon hozzáférést a kubelet-identitás kulcstartójához a az keyvault set-policy parancs használatával.

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 telepítése

Konfigurálja kubectl a Kubernetes-fürthöz való csatlakozást a az aks get-credentials paranccsal.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Hozzon létre egy új YAML-t gmsa-spec.yaml néven, és illessze be a következő YAML-be. Győződjön meg arról, hogy a helyőrzőket a saját értékeire cseréli.

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

Megjegyzés:

Az AKS frissítette a verziót windows.k8s.io/v1alpha1GMSACredentialSpecwindows.k8s.io/v1 a apiVersion v20230903-ban.

Hozzon létre egy gmsa-role.yaml nevű új YAML-t, és illessze be a következő YAML-be.

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

Hozzon létre egy új YAML-t gmsa-role-binding.yaml néven, és illessze be a következő YAML-be.

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

Alkalmazza a gmsa-spec.yaml, a gmsa-role.yaml és a gmsa-role-binding.yaml módosításait a kubectl apply parancs használatával.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

GMSA telepítésének ellenőrzése

Hozzon létre egy új YAML-t gmsa-demo.yaml néven, és illessze be a következő YAML-be.

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

Alkalmazza a gmsa-demo.yaml módosításait a kubectl apply parancs használatával.
```
kubectl apply -f gmsa-demo.yaml
```

Kérje le a mintaalkalmazás IP-címét a kubectl get service paranccsal.

kubectl get service gmsa-demo --watch

Kezdetben a EXTERNAL-IP szolgáltatás állapota függőben van:gmsa-demo

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

Ha a EXTERNAL-IP cím függőben lévőről tényleges nyilvános IP-címre változik, állítsa CTRL-C le a kubectl figyelés folyamatát.

Az alábbi példakimenet a szolgáltatáshoz rendelt érvényes nyilvános IP-címet jeleníti meg:
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Nyisson meg egy webböngészőt a szolgáltatás külső IP-címére gmsa-demo .
Hitelesítés a jelszóval és a $NETBIOS_DOMAIN_NAME\$AD_USERNAME jelszóval, és győződjön meg arról, hogy megjelenik Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

GMSA letiltása meglévő fürtön

Tiltsa le a GMSA-t egy meglévő fürtön Windows Server-csomópontokkal a az aks update parancs használatával.

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

Megjegyzés:

A GMSA újra engedélyezhető egy meglévő fürtön az az aks update paranccsal.

Hibaelhárítás

Ha az oldal betöltődik, de a rendszer nem kéri a hitelesítést, a kubectl logs POD_NAME paranccsal megjelenítheti a pod naplóit, és ellenőrizheti, hogy az IIS hitelesítéssel készen áll-e.

Megjegyzés:

A Windows-tárolók alapértelmezés szerint nem jelenítik meg a kubectl-naplókat. Ahhoz, hogy a Windows-tárolók megjeleníthessék a naplókat, be kell ágyaznia a Log Monitor eszközt a Windows rendszerképébe. További információ: Windows Container Tools.

Csatlakozás időtúllépés a lap betöltésekor

Ha a lap betöltésekor kapcsolati időtúllépést kap, ellenőrizze, hogy a mintaalkalmazás fut-e a kubectl get pods --watch paranccsal. Előfordulhat, hogy a mintaalkalmazás-szolgáltatás külső IP-címe elérhetővé válik a mintaalkalmazás-pod futtatása előtt.

A pod nem indul el, és winapi-hiba jelenik meg a podeseményekben

Ha a pod nem indul el a kubectl get pods --watch parancs futtatása és néhány perc várakozás után, használja a kubectl describe pod POD_NAME parancsot. Ha winapi-hibát lát a podeseményekben, az valószínűleg hiba a GMSA cred spec konfigurációjában. Ellenőrizze, hogy a gmsa-spec.yaml összes helyettesítő értéke helyes-e, újrafuttatva kubectl apply -f gmsa-spec.yamlés újból üzembe helyezi-e a mintaalkalmazást.

További lépések

További információ a Windows Server-tárolókról az AKS-en.

Csoport által felügyelt szolgáltatásfiókok (GMSA) engedélyezése a Windows Server-csomópontokhoz az Azure Kubernetes Service -fürtön

Előfeltételek

GMSA konfigurálása Az Active Directory tartományvezérlőn

A standard tartományi felhasználói hitelesítő adatok tárolása az Azure Key Vaultban

Nem kötelező: Egyéni virtuális hálózat használata egyéni DNS-sel

Nem kötelező: Több DNS-kiszolgáló konfigurálása

Nem kötelező: Saját kubelet-identitás használata a fürthöz

GMSA engedélyezése új AKS-fürtön

GMSA engedélyezése meglévő fürtön

Hozzáférés biztosítása a kubelet-identitás kulcstartójához

GMSA cred spec telepítése

GMSA telepítésének ellenőrzése

GMSA letiltása meglévő fürtön

Hibaelhárítás

A rendszer nem kér hitelesítést a lap betöltésekor

Csatlakozás időtúllépés a lap betöltésekor

A pod nem indul el, és winapi-hiba jelenik meg a podeseményekben

További lépések

További források