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

  • Статья

Область применения: 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 отсутствуют, но только контроллеры домена, работающие Windows Server 2012 или более поздних версий, могут распространять пароли gMSA. Дополнительные сведения см. в разделе Требования для групповых управляемых учетных записей служб.
  • Разрешение на создание учетной записи gMSA. Чтобы создать учетную запись gMSA, необходимо быть администратором домена или использовать учетную запись с разрешениями на создание объектов msDS-GroupManagedServiceAccount .
  • Доступ к Интернету для скачивания модуля PowerShell CredentialSpec . При работе в автономной среде можно сохранить модуль на компьютере с доступом к Интернету и скопировать его на компьютер разработки или узел контейнера.
  • Чтобы обеспечить работу проверки подлинности gMSA и AD, убедитесь, что узлы кластера Azure Stack HCI и Windows Server настроены для синхронизации времени с контроллером домена или другим источником времени. Необходимо также убедиться, что Hyper-V настроен для синхронизации времени с любыми виртуальными машинами.

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

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

  1. На контроллере домена подготовьте Active Directory и создайте учетную запись gMSA.

  2. Create учетную запись пользователя домена. Эти учетные данные учетной записи пользователя или пароля сохраняются в виде секрета Kubernetes и используются для получения пароля gMSA.

  3. Чтобы создать учетную запись 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, созданные для упрощения процесса настройки.

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

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

    Install-AksHciGMSAWebhook -Name <cluster name>

    Чтобы убедиться, что модуль pod веб-перехватчика успешно запущен, выполните следующую команду:

    kubectl get pods -n kube-system | findstr gmsa

    Вы увидите один модуль pod с префиксом gmsa-webhook , который выполняется.

  2. Create секретный объект, в котором хранятся учетные данные пользователя 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

    Примечание

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

  3. Используйте командлет 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

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

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

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

    serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

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

    securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

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

    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

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

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

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

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

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

    kubectl get pods

  2. Откройте PowerShell и выполните следующую команду:

    kubectl exec -it <container id> powershell

  3. Оказавшись в контейнере, выполните следующую команду:

    Nltest /parentdomain 
Nltest /sc_verify:<domain> 

    Connection Status = 0 0x0 NERR_Success The command completed successfully.

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

  4. Проверьте, может ли контейнер получить действительный билет на предоставление билета 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>

Дальнейшие действия