Настройка групповых управляемых учетных записей служб (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>

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