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


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

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

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