Включение групповых управляемых учетных записей (GMSA) для узлов сервера Windows в кластере Службы Azure Kubernetes (AKS)

Статья
08/02/2024

Групповые управляемые учетные записи служб (GMSA) — это учетная запись управляемого домена для нескольких серверов, которая обеспечивает автоматическое управление паролями, упрощенное управление именем субъекта-службы и возможность делегировать управление другими администраторами. С помощью Служба Azure Kubernetes (AKS) вы можете включить GMSA на узлах Windows Server, что позволяет контейнерам, работающим на узлах Windows Server, интегрироваться и управлять с помощью GMSA.

Необходимые компоненты

Kubernetes 1.19 или более поздней версии. Сведения о проверке версии см. в разделе "Проверка доступных обновлений". Сведения об обновлении версии см. в статье Об обновлении кластера AKS.
Azure CLI версии 2.35.0 или выше. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Управляемые удостоверения включены в кластере AKS.
Разрешения на создание или обновление Azure Key Vault.
Разрешения на настройку GMSA в службе домен Active Directory или локальная служба Active Directory.
На контроллере домена должны быть включены веб-службы Active Directory, и они должны быть доступны через порт 9389 кластера AKS.

Примечание.

Корпорация Майкрософт также предоставляет специально созданный модуль PowerShell для настройки gMSA в AKS. Дополнительные сведения см. в Служба Azure Kubernetes gMSA.

Настройка GMSA на контроллере домена Active Directory

Чтобы использовать GMSA с AKS, требуется стандартная учетная запись пользователя домена для доступа к учетным данным GMSA, настроенным на контроллере домена. Сведения о настройке GMSA на контроллере домена см. в статье "Начало работы с групповыми управляемыми учетными записями служб". В качестве учетных данных стандартного пользователя домена можно использовать учетные данные существующего пользователя или создать нового с доступом к учетным данным GMSA.

Внимание

Необходимо использовать службу домен Active Directory или локальная служба Active Directory. В настоящее время нельзя использовать идентификатор Microsoft Entra для настройки GMSA с кластером AKS.

Хранение учетных данных стандартного пользователя домена в Azure Key Vault

Кластер AKS использует учетные данные стандартного пользователя домена для доступа к учетным данным GMSA из контроллера домена. Чтобы обеспечить безопасный доступ к этим учетным данным для кластера AKS, их следует хранить в Azure Key Vault.

Если у вас еще нет хранилища ключей Azure, создайте его с помощью az keyvault create команды.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
Сохраните учетные данные пользователя домена уровня "Стандартный" в качестве секрета в хранилище ключей az keyvault secret set с помощью команды. В следующем примере хранятся учетные данные пользователя домена с ключом GMSADomainUserCred в хранилище ключей myGMSAVault .
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Примечание.

Обязательно используйте полное доменное имя для домена.

Необязательно. Использование настраиваемой виртуальной сети с пользовательским DNS

Необходимо настроить контроллер домена через DNS, чтобы он был доступен кластером AKS. Вы можете настроить сеть и DNS за пределами кластера AKS, чтобы разрешить кластеру доступ к контроллеру домена. Кроме того, вы можете использовать Azure CNI для настройки пользовательской виртуальной сети с пользовательским DNS в кластере AKS для предоставления доступа к контроллеру домена. Дополнительные сведения см. в разделе "Настройка сети Azure CNI" в Служба Azure Kubernetes (AKS).

Необязательно. Настройка нескольких DNS-серверов

Если вы хотите настроить несколько DNS-серверов для Windows GMSA в кластере AKS, не указывайте или v--gmsa-root-domain-nameне указывайте--gmsa-dns-server. Вместо этого можно добавить несколько DNS-серверов в виртуальную сеть, выбрав Пользовательский DNS и добавив DNS-серверы.

Необязательно: используйте собственное удостоверение kubelet для кластера

Чтобы у кластера AKS был доступ к вашему хранилищу ключей, этот доступ должен быть у удостоверения kubelet кластера. При создании кластера с включенным управляемым удостоверением удостоверение kubelet автоматически создается по умолчанию.

Вы можете предоставить доступ к хранилищу ключей для удостоверения после создания кластера или создать собственное удостоверение перед созданием кластера, выполнив следующие действия.

Создайте удостоверение kubelet с помощью az identity create команды.
```
az identity create --name myIdentity --resource-group myResourceGroup
```
Получите идентификатор удостоверения с помощью az identity list команды и задайте для нее переменную с именем MANAGED_ID.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```
Предоставьте удостоверению доступ к хранилищу ключей az keyvault set-policy с помощью команды.
```
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
```

Включение GMSA в новом кластере AKS

Создайте учетные данные администратора для использования во время создания кластера. Следующая команда запрашивает имя пользователя и задает для него значение WINDOWS_USERNAME для использования в следующей команде.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Создайте кластер AKS с помощью az aks create команды со следующими параметрами:
- --enable-windows-gmsa: включает GMSA для кластера.
- --gmsa-dns-server: IP-адрес DNS-сервера.
- --gmsa-root-domain-name: корневое доменное имя 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
```
Примечание.
- Если вы используете пользовательскую виртуальную сеть, необходимо указать идентификатор виртуальной сети с помощью vnet-subnet-id параметра, а также docker-bridge-addressdns-service-ipдобавить параметры и service-cidr параметры в зависимости от конфигурации.
- Если вы создали собственное удостоверение для удостоверения kubelet, используйте assign-kubelet-identity параметр для указания удостоверения.
- При указании --gmsa-dns-server и --gmsa-root-domain-name параметров правило пересылки DNS добавляется в kube-system/coredns ConfigMap. Это правило перенаправит DNS-запросы $ROOT_DOMAIN_NAME из модулей pod в $DNS_SERVER.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Добавьте пул узлов Windows Server с помощью az aks nodepool add команды.

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

Включение GMSA в существующем кластере

Включите GMSA в существующем кластере с узлами Windows Server и управляемыми удостоверениями, включенными с помощью 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
```

Предоставление доступа к хранилищу ключей для удостоверения kubelet

Примечание.

Пропустите этот шаг, если вы предоставили собственное удостоверение для удостоверения kubelet.

Предоставьте доступ к хранилищу ключей для удостоверения kubelet с помощью 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

Установка спецификации учетных данных GMSA

Настройте kubectl подключение к кластеру az aks get-credentials Kubernetes с помощью команды.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Создайте yamL с именем gmsa-spec.yaml и вставьте следующий yamL. Убедитесь, что заполнители заменяются собственными значениями.

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

Примечание.

AKS обновила apiVersion GMSACredentialSpec версию версии 20230903 с windows.k8s.io/v1alpha1 windows.k8s.io/v1 версии 20230903.

Создайте yamL с именем gmsa-role.yaml и вставьте следующий 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"]

Создайте yamL с именем gmsa-role-binding.yaml и вставьте следующий 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

Примените изменения из gmsa-spec.yaml, gmsa-role.yaml и gmsa-role-binding.yaml с помощью kubectl apply команды.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

Проверка установки GMSA

Создайте yamL с именем gmsa-demo.yaml и вставьте следующий 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

Примените изменения из gmsa-demo.yaml с помощью kubectl apply команды.
```
kubectl apply -f gmsa-demo.yaml
```
Получите IP-адрес примера приложения с помощью kubectl get service команды.
```
kubectl get service gmsa-demo --watch
```
EXTERNAL-IP Изначально служба отображается как ожидающаяgmsa-demo:
```
NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
gmsa-demo          LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s
```
EXTERNAL-IP Если адрес изменяется от ожидающего до фактического общедоступного IP-адреса, используйте CTRL-C для остановки kubectl процесса наблюдения.

В следующем примере выходных данных показан общедоступный IP-адрес, присвоенный службе.
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Откройте веб-браузер для внешнего IP-адреса gmsa-demo службы.
Проверка подлинности с помощью $NETBIOS_DOMAIN_NAME\$AD_USERNAME пароля и подтверждение.Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate

Отключение GMSA в существующем кластере

Отключите GMSA в существующем кластере с узлами Windows Server с помощью az aks update команды.
```
az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-windows-gmsa 
```

Примечание.

Вы можете повторно включить GMSA в существующем кластере с помощью команды az aks update .

Устранение неполадок

Если страница загружается, но вам не предлагается пройти проверку подлинности, используйте kubectl logs POD_NAME команду для отображения журналов pod и убедитесь, что службы IIS готовы к проверке подлинности.

Примечание.

Контейнеры Windows не будут отображать журналы в kubectl по умолчанию. Чтобы контейнеры Windows могли отображать журналы, необходимо внедрить средство Log Monitor в образ Windows. Дополнительные сведения см. в разделе "Средства контейнеров Windows".

Время ожидания соединения при попытке загрузить страницу

Если при попытке загрузить страницу вы получите время ожидания подключения, убедитесь, что пример приложения выполняется с помощью kubectl get pods --watch команды. Иногда внешний IP-адрес для примера службы приложений оказывается доступен до запуска примера модуля pod приложения.

Не удается запустить pod, и в событиях pod отображается ошибка winapi

Если модуль pod не запускается после выполнения kubectl get pods --watch команды и ожидает несколько минут, используйте kubectl describe pod POD_NAME команду. Если в событиях pod отображается ошибка winapi, скорее всего, это ошибка в конфигурации спецификации cred GMSA. Убедитесь, что все замененные значения в файле gmsa-spec.yaml правильные, повторно запустите kubectl apply -f gmsa-spec.yaml и разверните пример приложения.

Следующие шаги

Дополнительные сведения см. в рекомендациях по контейнерам Windows с Служба Azure Kubernetes (AKS).

Поделиться через

Включение групповых управляемых учетных записей (GMSA) для узлов сервера Windows в кластере Службы Azure Kubernetes (AKS)

Необходимые компоненты

Настройка GMSA на контроллере домена Active Directory

Хранение учетных данных стандартного пользователя домена в Azure Key Vault

Необязательно. Использование настраиваемой виртуальной сети с пользовательским DNS

Необязательно. Настройка нескольких DNS-серверов

Необязательно: используйте собственное удостоверение kubelet для кластера

Включение GMSA в новом кластере AKS

Включение GMSA в существующем кластере

Предоставление доступа к хранилищу ключей для удостоверения kubelet

Установка спецификации учетных данных GMSA

Проверка установки GMSA

Отключение GMSA в существующем кластере

Устранение неполадок

При загрузке страницы не выводится запрос на проверку подлинности.

Время ожидания соединения при попытке загрузить страницу

Не удается запустить pod, и в событиях pod отображается ошибка winapi

Следующие шаги

Дополнительные ресурсы