Настройка групповых управляемых учетных записей служб (gMSA) для контейнеров Windows с Служба Azure Kubernetes в Azure Stack HCI и Windows Server

Статья
02/13/2024

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

Чтобы использовать проверку подлинности AD, можно настроить групповые управляемые учетные записи служб (gMSA) для запуска контейнеров Windows с узлом, не присоединенным к домену. Групповая управляемая учетная запись службы — это особый тип учетной записи службы, появившись в Windows Server 2012 который позволяет нескольким компьютерам совместно использовать удостоверение, не зная пароля. Контейнеры Windows нельзя присоединять к домену, но для многих приложений Windows, которые работают в контейнерах Windows, требуется проверка подлинности AD.

Примечание

Чтобы узнать, как сообщество Kubernetes поддерживает использование gMSA с контейнерами Windows, см. статью Настройка gMSA.

Архитектура gMSA для контейнеров с узлом, не присоединенным к домену

gMSA для контейнеров с узлом, не присоединенным к домену, использует переносимое удостоверение пользователя вместо удостоверения узла для получения учетных данных gMSA. Поэтому ручное присоединение рабочих узлов Windows к домену больше не требуется. Личность пользователя сохраняется в Kubernetes в секрете. На схеме ниже показан процесс настройки gMSA для контейнеров с узлом, не присоединенным к домену:

Схема групповых управляемых учетных записей службы версии 2

gMSA для контейнеров с хостом, не присоединенным к домену, обеспечивает гибкость создания контейнеров с gMSA без присоединения хост-узла к домену. Начиная с Windows Server 2019 поддерживается ccg.exe, что позволяет использовать механизм подключаемого модуля для получения учетных данных gMSA из Active Directory. Это удостоверение можно применить для запуска контейнера. Дополнительные сведения о ccg.exe см. в разделе Интерфейс ICcgDomainAuthCredentials.

Сравнение gMSA для контейнеров с узлом, не присоединенным к домену, и узлом, присоединенным к домену

При первоначальном добавлении gMSA требовалось присоединение узла контейнера к домену, что привело к большим затратам на присоединение рабочих узлов Windows вручную к домену. Это ограничение устранено с помощью gMSA для контейнеров с узлом, не присоединенным к домену, поэтому пользователи теперь могут использовать gMSA с узлами, не присоединенными к домену. Вот еще несколько улучшений, внесенных в работу gMSA:

Устранение необходимости вручную присоединять рабочие узлы Windows к домену, что привело к большим затратам. Это упростит процессы в сценариях с использованием масштабирования.
В сценариях последовательного обновления пользователям больше не нужно повторно присоединить узел к домену.
Упрощен процесс управления учетными записями на компьютерах рабочих узлов, позволяющий получать пароли для групповой учетной записи службы.
Упрощен сквозной процесс настройки gMSA для Kubernetes.

Подготовка к работе

Чтобы запустить контейнер Windows с групповой управляемой учетной записью службы, вам потребуется следующее:

Домен Active Directory по меньшей мере с одним контроллером домена под управлением Windows Server 2012 или более поздней версии. Для использования gMSA нет требований к функциональному уровню леса или домена, но пароли gMSA могут распространяться только контроллерами домена, работающими Windows Server 2012 или более поздней версии. Дополнительные сведения см. в разделе Требования для групповых управляемых учетных записей служб.
Разрешение на создание учетной записи gMSA. Чтобы создать учетную запись gMSA, необходимо быть администратором домена или использовать учетную запись, которая получила разрешение на создание объектов msDS-GroupManagedServiceAccount.
Доступ к Интернету для скачивания модуля PowerShell CredentialSpec . При работе в автономной среде можно сохранить модуль на компьютере с доступом к Интернету и скопировать его на компьютер разработки или узел контейнера.
Чтобы обеспечить работу проверки подлинности gMSA и AD, убедитесь, что узлы кластера Azure Stack HCI и Windows Server настроены для синхронизации времени с контроллером домена или другим источником времени. Кроме того, необходимо убедиться, что Hyper-V настроен для синхронизации времени с любыми виртуальными машинами.

Подготовка gMSA на контроллере домена

Выполните следующие действия, чтобы подготовить gMSA в контроллере домена:

На контроллере домена подготовьте Active Directory и создайте учетную запись gMSA.
Создайте учетную запись пользователя домена. Эта учетная запись пользователя или пароль будут сохранены в виде секрета Kubernetes и использоваться для получения пароля gMSA.

Чтобы создать учетную запись GMSA и предоставить разрешение на чтение пароля для учетной записи gMSA, созданной на шаге 2, выполните следующую команду PowerShell New-ADServiceAccount :

 New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier>

Для -PrincipalsAllowedToRetrieveManagedPasswordукажите имя пользователя домена, созданное ранее, как показано в примере ниже:

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"

Подготовка JSON-файла спецификации учетных данных gMSA

Чтобы подготовить JSON-файл спецификации учетных данных gMSA, выполните действия по созданию спецификации учетных данных.

Настройка gMSA для модулей pod и контейнеров Windows в кластере

Сообщество Kubernetes уже поддерживает присоединенные к домену рабочие узлы Windows для gMSA. Хотя присоединение к рабочему узлу Windows в AKS в Azure Stack HCI и Windows Server не требуется, существуют и другие необходимые действия по настройке. Эти шаги включают установку веб-перехватчика, определения пользовательского ресурса (CRD) и спецификации учетных данных, а также включение управления доступом на основе ролей (роль RBAC). В следующих шагах используются команды PowerShell, созданные для упрощения процесса настройки.

Прежде чем выполнять приведенные ниже действия, убедитесь, что модуль PowerShell AksHci установлен и kubectl может подключиться к кластеру.

Чтобы установить веб-перехватчик, выполните следующую команду PowerShell Install-AksHciGmsaWebhook :
```
Install-AksHciGMSAWebhook -Name <cluster name>
```
Чтобы убедиться, что модуль pod веб-перехватчика успешно запущен, выполните следующую команду:
```
kubectl get pods -n kube-system | findstr gmsa
```
Вы увидите один модуль pod с запущенным префиксом gmsa-webhook .
Создайте секретный объект, в котором хранятся учетные данные пользователя Active Directory. Заполните приведенные ниже данные конфигурации и сохраните параметры в файл с именем secret.yaml.
```
apiVersion: v1
kind: Secret
metadata:
   name: <secret-name>
   namespace: <secret under namespace other than the default>
type: Opaque
stringData:
   domain: <FQDN of the domain, for example: akshcitest.com>
   username: <domain user who can retrieve the gMSA password>
   password: <password>
```
Затем выполните следующую команду, чтобы создать объект secret:
```
kubectl apply -f secret.yaml
```
Примечание

Если вы создаете секрет в пространстве имен, отличном от пространства имен по умолчанию, не забудьте задать для пространства имен развертывания то же пространство имен.
Используйте командлет PowerShell Add-AksHciGMSACredentialSpec , чтобы создать crD gMSA, включить управление доступом на основе ролей (RBAC), а затем назначить роль учетным записям служб, чтобы использовать конкретный файл спецификации учетных данных gMSA. Эти действия более подробно описаны в этой статье Kubernetes о настройке gMSA для модулей pod и контейнеров Windows.

Используйте спецификацию учетных данных JSON в качестве входных данных для следующей команды PowerShell (параметры со звездочками * являются обязательными):
```
Add-AksHciGMSACredentialSpec -Name <cluster name>*  
  -credSpecFilePath <path to JSON credspec>* 
  -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
  -secretName <name of secret>* 
  -secretNamespace <namespace of secret>  
  -serviceAccount <name of service account to bind to clusterrole>  
  -clusterRoleName <name of clusterrole to use the credspec>*  
  -overwrite 
```
Чтобы просмотреть пример, см. следующий код:
```
Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster
```

Развертывание приложения

Создайте YAML-файл развертывания, используя следующие примеры параметров. Обязательные записи включают serviceAccountName, gmsaCredentialSpecName, volumeMountsи dnsconfig.

Добавьте учетную запись службы:

serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

Добавьте объект спецификации учетных данных:

securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

Подключите секрет для развертывания:

volumeMounts:
     - name: <volume name>
       mountPath: <vmount path>
       readOnly: true
   volumes:
     - name: <volume name>
       secret:
         secretName: <secret name>
         items:
           - key: username
             path: my-group/my-username

Добавьте IP-адрес контроллера домена и доменное имя в dnsConfig:

dnsConfig: 
     nameservers:
       - <IP address for domain controller>
     searches: 
       - <domain>

Убедитесь, что контейнер работает с gMSA

После развертывания контейнера выполните следующие действия, чтобы убедиться, что он работает:

Получите идентификатор контейнера для развертывания, выполнив следующую команду:
```
kubectl get pods
```
Откройте PowerShell и выполните следующую команду:
```
kubectl exec -it <container id> powershell
```
Оказавшись в контейнере, выполните следующую команду:
```
Nltest /parentdomain 
Nltest /sc_verify:<domain> 
```
```
Connection Status = 0 0x0 NERR_Success The command completed successfully. 
```
Эти выходные данные показывают, что компьютер прошел проверку подлинности с помощью контроллера домена, а между клиентским компьютером и контроллером домена существует безопасный канал.
Проверьте, может ли контейнер получить действительный билет на предоставление билета Kerberos (TGT).
```
klist get krbtgt
```
```
A ticket to krbtgt has been retrieved successfully
```

Очистка параметров gMSA в кластере

Если вам нужно очистить параметры gMSA, выполните следующие действия по удалению.

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

Чтобы удалить, выполните следующую команду PowerShell Remove-AksHcigmsaCredentialSpec :

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

Удаление веб-перехватчика

Чтобы удалить веб-перехватчик, выполните следующую команду PowerShell Uninstall-AksHciGMSAWebhook :

Uninstall-AksHciGMSAWebhook -Name <cluster name>