Создание gMSAs для контейнеров Windows

Статья
01/27/2025

Область применения: Windows Server 2025, Windows Server 2022, Windows Server 2019

Сети под управлением Windows обычно используют Active Directory (AD) для упрощения проверки подлинности и авторизации между пользователями, компьютерами и другими сетевыми ресурсами. Разработчики корпоративных приложений часто разрабатывают приложения для интеграции с AD и запускаются на серверах, присоединенных к домену, чтобы воспользоваться преимуществами встроенной проверки подлинности Windows, что упрощает автоматический и прозрачный вход пользователей и других служб в приложение с помощью удостоверений. В этой статье объясняется, как начать использовать управляемые учетные записи служб группы Active Directory с контейнерами Windows.

Хотя контейнеры Windows не могут быть присоединены к домену, они по-прежнему могут использовать удостоверения домена Active Directory для поддержки различных сценариев проверки подлинности. Для этого можно настроить контейнер Windows для запуска с помощью групповой управляемой учетной записи службы (gMSA), которая является специальным типом учетной записи службы, введенного в Windows Server 2012 и предназначенного для предоставления нескольким компьютерам общего доступа к удостоверению без необходимости знать его пароль. Контейнеры Windows не могут быть присоединены к домену, но многие приложения Windows, которые выполняются в контейнерах Windows, по-прежнему требуют проверки подлинности AD. Чтобы использовать проверку подлинности AD, можно настроить контейнер Windows для запуска с помощью групповой управляемой учетной записи службы (gMSA).

При первоначальном внедрении gMSA для контейнеров Windows требовалось, чтобы узел контейнера был присоединен к домену, что создавало значительные административные нагрузки для пользователей, вынужденных вручную присоединять рабочие узлы Windows к домену. Это ограничение было устранено с помощью gMSA для поддержки контейнеров Windows на узлах, не присоединённых к домену. Мы будем продолжать поддерживать исходную функциональность gMSA для использования контейнерного узла, присоединенного к домену.

Улучшения gMSA при использовании контейнерного хоста, не присоединенного к домену, включают:

Требование вручную присоединить рабочие узлы Windows к домену устраняется, так как это привело к большим затратам для пользователей. В сценариях масштабирования использование хоста контейнера, не присоединенного к домену, упрощает процесс.
В сценариях последовательного обновления пользователи больше не должны повторно присоединить узел к домену.
Управление учетными записями компьютера рабочего узла для получения паролей учетных записей службы gMSA упрощается.
Настройка gMSA с помощью Kubernetes является менее сложным комплексным процессом.

Заметка

Чтобы узнать, как сообщество Kubernetes поддерживает использование gMSA с контейнерами Windows, см. настройке gMSA.

Архитектура и усовершенствования gMSA

Чтобы устранить ограничения начальной реализации gMSA для контейнеров Windows, новая поддержка gMSA для узлов контейнеров, не присоединенных к домену, использует переносимое удостоверение пользователя вместо учетной записи компьютера узла для получения учетных данных gMSA. Поэтому вручную присоединение рабочих узлов Windows к домену больше не требуется, хотя оно по-прежнему поддерживается. Удостоверение пользователя или учетные данные хранятся в хранилище секретов, доступном узлу контейнера (например, в качестве секрета Kubernetes), где прошедшие проверку подлинности пользователи могут получить его.

Схема управляемых сервисных учетных записей групп второй версии

Поддержка gMSA для узлов контейнеров, не присоединенных к домену, обеспечивает гибкость создания контейнеров с помощью gMSA без присоединения узла к домену. Начиная с Windows Server 2019, ccg.exe поддерживается, что позволяет механизму подключаемого модуля получать учетные данные gMSA из Active Directory. Это удостоверение можно использовать для запуска контейнера. Дополнительные сведения об этом механизме подключения см. в интерфейсе ICcgDomainAuthCredentials.

Заметка

В службе Azure Kubernetes в Azure Stack HCI можно использовать подключаемый модуль для обмена данными из ccg.exe в AD, а затем получить учетные данные gMSA. Дополнительные сведения см. в статье настроить управляемую группой учетную запись службы с помощью AKS в Azure Stack HCI.

Изучите схему ниже, чтобы следовать шагам процесса Container Credential Guard:

С помощью файла CredSpec в качестве входных данных процесс ccg.exe запускается на узле узла.
ccg.exe использует сведения в файле CredSpec для запуска подключаемого модуля, а затем получения учетных данных учетной записи в хранилище секретов, связанном с подключаемым модулем.
ccg.exe использует полученные учетные данные учетной записи для получения пароля gMSA из AD.
ccg.exe делает пароль gMSA доступным для контейнера, который запрашивал учетные данные.
Контейнер аутентифицируется на контроллере домена с помощью пароля gMSA для получения билета Kerberos Ticket-Granting (TGT).
Приложения, работающие как сетевая служба или локальная система в контейнере, теперь могут проходить проверку подлинности и получать доступ к ресурсам домена, таким как gMSA.

Необходимые условия

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

Домен Active Directory с по крайней мере одним контроллером домена под управлением Windows Server 2012 или более поздней версии. Для использования gMSAs нет требований к лесу или функциональному уровню домена, но пароли gMSA могут распределяться только контроллерами домена, работающими на Windows Server 2012 или более поздней версии. Дополнительные сведения см. в разделе требования Active Directory для gMSAs.
Разрешение на создание учетной записи gMSA. Чтобы создать учетную запись gMSA, необходимо быть администратором домена или использовать учетную запись, которой делегировано право создания объектов msDS-GroupManagedServiceAccount.
Доступ к Интернету для скачивания модуля CredentialSpec PowerShell. Если вы работаете в отключенной среде, вы можете сохранить модуль на компьютере с доступом к Интернету и скопировать его на компьютер разработки или узел контейнера.

Однократная подготовка Active Directory

Если вы еще не создали gMSA в домене, вам потребуется создать корневой ключ службы распространения ключей (KDS). KDS отвечает за создание, обновление и распространение пароля gMSA авторизованным узлам. Если узлу контейнера нужно использовать gMSA для запуска контейнера, он обратится к KDS для получения текущего пароля.

Чтобы проверить, уже создан корневой ключ KDS, выполните следующий командлет PowerShell в качестве администратора домена на контроллере домена или члене домена с установленными средствами AD PowerShell:

Get-KdsRootKey

Если команда возвращает идентификатор ключа, всё готово и можете перейти к разделу созданию управляемой групповой учетной записи службы. В противном случае перейдите к созданию корневого ключа KDS.

Важный

Для каждого леса следует создать только один корневой ключ KDS. Если создаются несколько корневых ключей KDS, это приведет к сбою gMSA после вращения пароля gMSA.

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

# For production environments
Add-KdsRootKey -EffectiveImmediately

Хотя команда подразумевает, что ключ будет эффективным немедленно, вам потребуется ждать 10 часов, прежде чем корневой ключ KDS реплицируется и доступен для использования на всех контроллерах домена.

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

Важный

Не используйте этот метод в рабочей среде.

# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Создать управляемую учетную запись службы для группы

Для каждого контейнера, использующего встроенную проверку подлинности Windows, требуется по крайней мере одна gMSA. Основная gMSA используется всякий раз, когда приложения, работающие в качестве системы или сетевой службы, обращаются к ресурсам в сети. Имя gMSA станет именем контейнера в сети независимо от имени узла, назначенного контейнеру. Контейнеры также можно настроить с помощью дополнительных GMSAs, если вы хотите запустить службу или приложение в контейнере в качестве другого удостоверения, отличного от учетной записи компьютера контейнера.

При создании gMSA вы также создаете общую учетную запись, которую можно одновременно использовать на множестве различных компьютеров. Доступ к паролю gMSA защищен списком управления доступом Active Directory. Мы рекомендуем создать группу безопасности для каждой учетной записи gMSA и добавить соответствующие узлы контейнеров в группу безопасности, чтобы ограничить доступ к паролю.

Наконец, так как контейнеры не регистрируют служебные имена участников (SPN) автоматически, вам потребуется вручную создать хотя бы хост SPN для вашей учетной записи gMSA.

Как правило, SPN хоста или http-регистрация используется с таким же именем, как учетная запись gMSA, но может потребоваться использовать другое имя службы, если клиенты подключаются к контейнерному приложению через балансировщик нагрузки или по DNS-имени, отличающемуся от имени gMSA.

Например, если учетная запись gMSA называется "WebApp01", но пользователи получают доступ к сайту по mysite.contoso.com, следует зарегистрировать http/mysite.contoso.com SPN на учетной записи gMSA.

Для некоторых приложений могут потребоваться дополнительные SPN для их уникальных протоколов. Например, для SQL Server требуется MSSQLSvc/hostname SPN.

В следующей таблице перечислены необходимые атрибуты для создания gMSA.

Свойство gMSA	Обязательное значение	Пример
Имя	Любое допустимое имя учетной записи.	`WebApp01`
имя хоста DNS	Доменное имя, добавленное к имени учетной записи.	`WebApp01.contoso.com`
ServicePrincipalNames	Задайте как минимум SPN участника, добавьте другие протоколы по мере необходимости.	`'host/WebApp01', 'host/WebApp01.contoso.com'`
Пользователи, имеющие право получать управляемый пароль	Группа безопасности, содержащая ваши узлы контейнеров.	`WebApp01Hosts`

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

Совет

Необходимо использовать учетную запись, которая принадлежит к группе безопасности администраторов домена , или которому было делегировано разрешение на создание объектов msDS-GroupManagedServiceAccount, чтобы выполнить следующие команды. Командлет New-ADServiceAccount является частью инструментов AD PowerShell из пакета инструментов удаленного администрирования сервера.

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

Вариант создания учетной записи gMSA для узлов контейнеров, присоединенных к домену

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName "WebApp01Hosts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$", "ContainerHost02$", "ContainerHost03$"

Вариант создания учетной записи gMSA для узлов контейнеров, не присоединенных к домену

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

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName "WebApp01Accounts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"

# Create the standard user account. This account information needs to be stored in a secret store and will be retrieved by the ccg.exe hosted plug-in to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with a unique username and password. We recommend using a random, long, machine-generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled 1

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"

Подготовка узла размещения контейнеров

Вариант использования для подготовки контейнерного узла, присоединенного к домену

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

Присоедините компьютер к домену Active Directory.
Убедитесь, что ваш хост принадлежит группе безопасности, контролирующей доступ к паролю gMSA.
Перезапустите компьютер, чтобы получить новое членство в группах.
Настройте Docker Desktop для Windows 10 или Docker для Windows Server.

(Рекомендуется) Убедитесь, что узел может использовать учетную запись gMSA, выполнив Test-ADServiceAccount. Если команда возвращает false, следуйте инструкциям по устранению неполадок.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

Test-ADServiceAccount WebApp01

Сценарий использования для подготовки узла контейнера, не присоединенного к домену

При использовании gMSA для контейнеров Windows на не присоединенных к домену узлах контейнера, на каждом узле контейнера должен быть установлен плагин для ccg.exe. Этот плагин будет использоваться для получения переносимой учетной записи пользователя и учетных данных, указанных на предыдущем шаге. Подключаемые модули уникальны для хранилища секретов, используемого для защиты учетных данных мобильной учетной записи пользователя. Например, для хранения учетных данных учетной записи в Azure Key Vault в отличие от хранилища секретов Kubernetes потребуются разные подключаемые модули.

В настоящее время Windows не предлагает встроенный модуль plug-in по умолчанию. Инструкции по установке подключаемых модулей будут зависеть от реализации. Дополнительные сведения о создании и регистрации подключаемых модулей для ccg.exeможно найти в интерфейсе ICcgDomainAuthCredentials.

Создание спецификации учетных данных

Файл спецификации учетных данных — это документ JSON, содержащий метаданные об учетных записях gMSA, которые вы хотите использовать в контейнере. Сохраняя конфигурацию удостоверения отдельно от образа контейнера, можно изменить, какую gMSA контейнер использует, просто переключив файл спецификации учетных данных, никаких изменений кода не требуется.

Файл спецификации учетных данных создается с помощью модуля CredentialSpec PowerShell на компьютере, присоединенном к домену. После создания файла его можно скопировать в другие узлы контейнеров или в оркестратор контейнеров. Файл спецификации учетных данных не содержит секретов, таких как пароль gMSA, так как узел контейнера извлекает учетную запись gMSA от имени контейнера.

Docker ожидает найти файл спецификации учетных данных в каталоге данных Docker CredentialSpecs. В установке по умолчанию эта папка будет находиться в C:\ProgramData\Docker\CredentialSpecs.

Чтобы создать файл спецификации учетных данных на узле контейнера:

Установка средств RSAT AD PowerShell
- Для Windows Server запустите Install-WindowsFeature RSAT-AD-PowerShell.
- Для Windows 10 версии 1809 или более поздней запустите Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~0.0.1.0".
- Для более старых версий Windows 10 см. https://aka.ms/rsat.
Выполните следующий командлет, чтобы установить последнюю версию модуля PowerShellCredentialSpec:
```
Install-Module CredentialSpec
```
Если у вас нет доступа к Интернету на узле контейнера, запустите Save-Module CredentialSpec на компьютере, подключенном к Интернету, и скопируйте папку модуля в C:\Program Files\WindowsPowerShell\Modules или в другое расположение в $env:PSModulePath на узле контейнера.
Выполните следующий командлет, чтобы создать новый файл спецификации учетных данных:
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
По умолчанию командлет создаёт спецификацию учетных данных, используя указанное имя gMSA в качестве учетной записи компьютера для контейнера. Файл будет сохранен в каталоге Docker CredentialSpecs, причём для имени файла будут использоваться домен gMSA и имя учетной записи.

Если вы хотите сохранить файл в другой каталог, используйте параметр -Path:
```
New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
```
Вы также можете создать спецификацию учетных данных, которая включает дополнительные учетные записи gMSA, если вы выполняете службу или процесс в качестве вторичной gMSA в контейнере. Для этого используйте параметр -AdditionalAccounts:
```
New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
```
Для полного списка поддерживаемых параметров выполните Get-Help New-CredentialSpec -Full.
Список всех спецификаций учетных данных и их полный путь можно отобразить с помощью следующего командлета:
```
Get-CredentialSpec
```

Это пример спецификации для учетных данных:

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ]
    }
}

Дополнительная конфигурация спецификации учетных данных для варианта использования узла контейнера, не присоединенного к домену

При использовании gMSA с узлами контейнеров, не присоединенными к домену, нужно добавить сведения о подключаемом модуле ccg.exe в спецификацию учетных данных. Это будет добавлено в раздел спецификации учетных данных с именем HostAccountConfig. В разделе hostAccountConfig есть три поля, которые необходимо заполнить:

PortableCcgVersion: это значение должно иметь значение "1".
PluginGUID: COM CLSID для плагина ccg.exe. Это уникально для используемого подключаемого модуля.
PluginInput: специфические входные данные плагина для получения сведений об учетной записи пользователя из секретного хранилища.

Это пример описания учетных данных с включённым разделом HostAccountConfig:

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ],
        "HostAccountConfig": {
            "PortableCcgVersion": "1",
            "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
            "PluginInput": "contoso.com:gmsaccg:<password>"
        }
    }
}

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

Теперь, когда вы настроили учетную запись gMSA, ее можно использовать для:

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

Дополнительные ресурсы

Дополнительные сведения о gMSAs см. в обзоре групп управляемых учетных записей служб.

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

Создание gMSAs для контейнеров Windows

Архитектура и усовершенствования gMSA

Необходимые условия

Однократная подготовка Active Directory

Создать управляемую учетную запись службы для группы

Вариант создания учетной записи gMSA для узлов контейнеров, присоединенных к домену

Вариант создания учетной записи gMSA для узлов контейнеров, не присоединенных к домену

Подготовка узла размещения контейнеров

Вариант использования для подготовки контейнерного узла, присоединенного к домену

Сценарий использования для подготовки узла контейнера, не присоединенного к домену

Создание спецификации учетных данных

Дополнительная конфигурация спецификации учетных данных для варианта использования узла контейнера, не присоединенного к домену

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

Дополнительные ресурсы

Обратная связь

Дополнительные ресурсы