Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: AKS на Windows Server
Чтобы использовать проверку подлинности AD, можно настроить групповые управляемые учетные записи служб (gMSA) для контейнеров Windows для запуска с узлом, не присоединенным к домену. Групповая управляемая служебная учетная запись — это особый тип учетной записи службы, появившийся в Windows Server 2012 и предназначенный для того, чтобы несколько компьютеров могли совместно использовать одно удостоверение, не зная пароля. Контейнеры Windows нельзя присоединять к домену, но для многих приложений Windows, которые работают в контейнерах Windows, требуется проверка подлинности AD.
Примечание.
Сведения о том, как сообщество Kubernetes поддерживает использование gMSA с контейнерами Windows, см. в статье "Настройка gMSA".
Архитектура gMSA для контейнеров с узлом, не присоединенным к домену
gMSA для контейнеров с не присоединенным к домену узлом использует переносимое удостоверение пользователя вместо удостоверения узла для получения учетных данных gMSA. Поэтому вручную присоединение рабочих узлов Windows к домену больше не требуется. Личность пользователя сохраняется в Kubernetes в секрете. На следующей схеме показан процесс настройки gMSA для контейнеров с не присоединённым к домену узлом.
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 в контроллере домена:
На контроллере домена подготовьте Active Directory и создайте учетную запись gMSA.
Создайте учетную запись пользователя домена. Эти учетные данные пользователя сохраняются в виде секрета Kubernetes и используются для получения пароля gMSA.
Чтобы создать учетную запись 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
может подключиться к кластеру.
Чтобы установить веб-перехватчик, выполните следующую команду Install-AksHciGmsaWebhook PowerShell:
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>
Затем выполните следующую команду, чтобы создать секретный объект:
kubectl apply -f secret.yaml
Примечание.
Если вы создаете секрет в пространстве имен, отличном от стандартного, не забудьте установить пространство имен развертывания таким же.
Используйте командлет 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
, 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, выполните следующие действия по удалению.
Удалите спецификацию учетных данных
Чтобы удалить, выполните следующую команду 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>