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

Статья
03/18/2023

Область применения: 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 нужно было подключать к домену вручную. Это ограничение устранено путем реализации для контейнеров Windows поддержки в gMSA узлов контейнеров, не присоединенных к домену. Мы продолжим поддерживать исходную функциональность gMSA для использования узла контейнера, присоединенного к домену.

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

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

Примечание.

Сведения о том, как сообщество Kubernetes поддерживает использование gMSA в контейнерах Windows, см.на странице о настройке gMSA.

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

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

Diagram of group Managed Service Accounts version two

Поддержка узлов контейнеров, не присоединенных к домену, в 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.

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

Необходимые компоненты

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

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

Единоразовая подготовка Active Directory

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

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

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 станет именем контейнера в сети независимо от имени узла, назначенного контейнеру. Кроме того, контейнеры можно настроить с помощью дополнительной gMSA, если вы хотите запустить службу или приложение в контейнере от имени другого удостоверения из учетной записи компьютера контейнера.

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

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

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

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

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

Перечень добавляемых атрибутов для создания gMSA указан в таблице ниже.

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

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

Совет

Чтобы выполнить следующие команды, необходимо использовать учетную запись, которая принадлежит группе безопасности Администраторы домена или которой делегировано разрешение Create msDS-GroupManagedServiceAccount objects. Командлет 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 не предлагает встроенный подключаемый модуль по умолчанию. Инструкции по установке для подключаемых модулей будут зависеть от реализации. Дополнительные сведения о создании и регистрации подключаемых модулей для ccg.exe см. в статье Интерфейс ICcgDomainAuthCredentials.

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

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

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

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

Чтобы создать файл спецификации учетных данных на узле контейнера, выполните следующие действия.

Установите средства удаленного администрирования сервера 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.
Выполните следующий командлет, чтобы установить последнюю версию модуля CredentialSpec среды PowerShell:
```
Install-Module CredentialSpec
```
Если у вас нет доступа к Интернету в узле контейнера, запустите Save-Module CredentialSpec на компьютере, подключенном к Интернету, и скопируйте папку модуля в C:\Program Files\WindowsPowerShell\Modules или другое расположение в $env:PSModulePath в узле контейнера.
Запустите следующий командлет, чтобы создать файл спецификации учетных данных:
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
По умолчанию командлет создаст файл спецификации учетных данных, используя предоставленное имя gMSA в качестве учетной записи компьютера контейнера. Файл будет сохранен в каталоге CredentialSpecs Docker с использованием в названии файла имени домена и учетной записи 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, с ее помощью можно выполнить следующие действия:

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

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

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

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

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

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

Необходимые компоненты

Единоразовая подготовка Active Directory

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

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

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

Подготовка узла контейнера

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

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

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

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

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

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

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

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