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

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

  • Статья

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

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

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

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

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

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

     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 и Windows Server, необходимо выполнить другие необходимые действия по настройке. К этим действиям относятся установка веб-перехватчика, пользовательское определение ресурсов (CRD) и спецификация учетных данных, а также включение управления доступом на основе ролей (роль RBAC). В следующих шагах используются команды PowerShell, созданные для упрощения процесса настройки.

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

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

    Install-AksHciGMSAWebhook -Name <cluster name>

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

    kubectl get pods -n kube-system | findstr gmsa

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

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

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

    kubectl apply -f secret.yaml

    Примечание.

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

  3. Используйте командлет Add-AksHciGMSACredentialSpec PowerShell, чтобы создать gMSA CRD, включить управление доступом на основе ролей (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, gmsaCredentialSpecNamevolumeMountsи 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, выполните следующие действия по удалению.

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

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

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

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

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

Uninstall-AksHciGMSAWebhook -Name <cluster name>

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