Créer des comptes de service administré de groupe pour des conteneurs Windows

Article
03/20/2023

S’applique à : Windows Server 2022, Windows Server 2019

Les réseaux Windows utilisent couramment Active Directory (AD) pour faciliter l’authentification et l’autorisation entre utilisateurs, ordinateurs et autres ressources réseau. Les développeurs d’applications d’entreprise conçoivent souvent leurs applications pour qu’elles soient intégrées avec AD et s’exécutent sur des serveurs joints à un domaine afin de tirer parti de l’authentification Windows intégrée, ce qui facilite pour les utilisateurs et d’autres services la connexion automatique et transparente à l’application avec leurs identités. Cet article explique comment commencer à utiliser des comptes de service administré de groupe Active Directory avec des conteneurs Windows.

Si les conteneurs Windows ne peuvent pas être joints à un domaine, ils peuvent toujours utiliser des identités de domaine Active Directory pour divers scénarios d’authentification. Pour ce faire, vous pouvez configurer un conteneur Windows pour qu’il s’exécute avec un compte de service administré de groupe (gMSA), qui est un type spécial de compte de service introduit dans Windows Server 2012 et conçu pour permettre à plusieurs ordinateurs de partager une identité sans avoir besoin de connaître son mot de passe. Les conteneurs Windows ne peuvent pas être joints à un domaine, mais de nombreuses applications Windows qui s’exécutent dans des conteneurs Windows ont encore besoin d’une authentification AD. Pour utiliser l’authentification AD, vous pouvez configurer un conteneur Windows afin qu’il s’exécute avec un compte de service administré de groupe (gMSA).

Lors de l’introduction initiale de gMSA pour les conteneurs Windows, l’hôte de conteneur devait être joint à un domaine, ce qui générait une surcharge de travail importante pour les utilisateurs, car ils devaient joindre manuellement les nœuds Worker Windows à un domaine. Cette limitation a été levée via la prise en charge par gMSA pour les conteneurs Windows des hôtes de conteneur non joints à un domaine. Nous allons continuer à prendre en charge la fonctionnalité gMSA d’origine pour utiliser un hôte de conteneur joint à un domaine.

Les améliorations apportées à gMSA lors de l’utilisation d’un hôte de conteneur non joint à un domaine comprennent :

L’obligation de joindre manuellement des nœuds worker Windows à un domaine n’existe plus, car elle a provoqué beaucoup de surcharge pour les utilisateurs. Pour les scénarios de mise à l’échelle, l’utilisation d’un hôte de conteneur non joint à un domaine simplifie le processus.
Dans les scénarios de mise à jour propagée, les utilisateurs ne doivent plus joindre le nœud à un domaine.
La gestion des comptes d’ordinateur de nœuds worker pour récupérer les mots de passe des comptes de service gMSA est un processus plus simple.
La configuration de gMSA avec Kubernetes est un processus de bout en bout moins complexe.

Remarque

Pour savoir comment la communauté Kubernetes prend en charge l’utilisation de gMSA avec des conteneurs Windows, consultez ce document sur la configuration de gMSA.

Architecture et améliorations des gMSA

Pour lever les limitations de l’implémentation initiale de gMSA pour les conteneurs Windows, la nouvelle prise en charge par gMSA des hôtes de conteneurs non joints à un domaine utilise une identité d’utilisateur portable au lieu d’un compte d’ordinateur hôte pour récupérer les informations d’identification de gMSA. Par conséquent, il n’est plus nécessaire de joindre manuellement les nœuds worker Windows à un domaine, bien que cette option reste possible. L’identité/les informations d’identification de l’utilisateur sont stockées dans un magasin de secrets accessible à l’hôte du conteneur (par exemple en tant que secret Kubernetes) où les utilisateurs authentifiés peuvent les récupérer.

Diagram of group Managed Service Accounts version two

La prise en charge par gMSA des conteneurs non joints à un domaine rend possible la création de conteneurs avec gMSA sans joindre le nœud hôte au domaine. À compter de Windows Server 2019, ccg.exe est pris en charge, ce qui permet à un mécanisme de plug-in de récupérer des informations d’identification gMSA à partir d’Active Directory. Vous pouvez utiliser cette identité pour démarrer le conteneur. Pour plus d’informations sur me mécanisme de ce plug-in, reportez-vous à l’interface ICcgDomainAuthCredentials.

Notes

Dans Azure Kubernetes Service sur Azure Stack HCI, vous pouvez utiliser le plug-in pour permettre la communication de ccg.exe vers AD, puis la récupération des informations d’identification gMSA. Pour plus d’informations, consultez Configurer un compte de service administré de groupe avec AKS sur Azure Stack HCI.

Aidez-vous du diagramme ci-dessous pour effectuer les étapes du processus Container Credential Guard :

En utilisant un fichier CredSpec comme entrée, le processus ccg.exe est démarré sur le nœud hôte.
ccg.exe utilise les informations contenues dans le fichier CredSpec pour lancer un plug-in, et récupérer ensuite les informations d’identification du compte dans le magasin des secrets associé au plug-in.
ccg.exe utilise les informations d’identification du compte obtenues afin de récupérer le mot de passe gMSA auprès d’AD.
ccg.exe fournit le mot de passe gMSA à un conteneur qui a demandé des informations d’identification.
Le conteneur s’authentifie auprès du contrôleur de domaine à l’aide du mot de passe gMSA pour obtenir un ticket TGT (Ticket-Granting Ticket).
Les applications qui s’exécutent en tant que service réseau ou système local dans le conteneur peuvent alors s’authentifier et accéder aux ressources du domaine, telles que les gMSA.

Prérequis

Pour exécuter un conteneur Windows avec un compte de service administré de groupe, vous aurez besoin des éléments suivants :

Un domaine Active Directory avec au moins un contrôleur de domaine exécutant Windows Server 2012 ou version ultérieure. Aucune exigence de niveau fonctionnel de forêt ou de domaine n’est liée à l’utilisation de comptes de service administré de groupe, mais les mots de passe de ceux-ci ne peuvent être distribués que par des contrôleurs de domaine exécutant Windows Server 2012 ou version ultérieure. Pour plus d’informations, consultez Exigences Active Directory pour les comptes de service administré de groupe.
L’autorisation de créer un compte de service administré de groupe. Pour créer un compte de service administré de groupe, vous devez être administrateur de domaine ou utiliser un compte auquel est déléguée l’autorisation Créer des objets msDS-GroupManagedServiceAccount.
Un accès à Internet pour télécharger le module PowerShell CredentialSpec. Si vous travaillez dans un environnement déconnecté, vous pouvez enregistrer le module sur un ordinateur disposant d’un accès à Internet et le copier sur votre ordinateur de développement ou hôte de conteneur.

Préparation unique d’Active Directory

Si vous n’avez pas encore créé de compte de service administré de groupe dans votre domaine, vous devez générer la clé racine du service de distribution de clés. Le service de distribution de clés est chargé de la création, de la rotation et de la publication du mot de passe de compte de service administré de groupe pour les hôtes autorisés. Quand un hôte de conteneur doit utiliser le compte de service administré de groupe pour exécuter un conteneur, il contacte le service de distribution de clés pour récupérer le mot de passe actuel.

Pour vérifier si la clé racine du service de distribution de clés a déjà été créée, exécutez la cmdlet PowerShell suivante en tant qu’administrateur de domaine sur un contrôleur de domaine ou un membre de domaine sur lequel les outils AD PowerShell sont installés :

Get-KdsRootKey

Si la commande retourne un ID de clé, vous êtes prêt et pouvez passer directement à la section Créer un compte de service administré de groupe. Sinon, poursuivez pour créer la clé racine du service de distribution de clés.

Important

Vous ne devez créer qu’une seule clé racine KDS par forêt. Si plusieurs clés racines KDS sont créées, cela entraîne l’échec du compte gMSA après la rotation du mot de passe gMSA.

Dans un environnement de production ou de test comptant plusieurs contrôleurs de domaine, exécutez la cmdlet suivante dans PowerShell en tant qu’administrateur de domaine pour créer la clé racine du service de distribution de clés.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Bien que la commande implique que la clé prendra effet immédiatement, vous devrez attendre 10 heures avant que la clé racine du service de distribution de clés soit répliquée et disponible pour utilisation sur tous les contrôleurs de domaine.

Si vous n’avez qu’un seul contrôleur de domaine dans votre domaine, vous pouvez accélérer le processus en définissant l’horodatage de prise d’effet de la clé pour 10 heures plut tôt.

Important

N’utilisez pas cette technique dans un environnement de production.

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

Créer un compte de service administré de groupe

Chaque conteneur utilisant l’authentification Windows intégrée a besoin d’au moins un compte de service administré de groupe. Le compte de service administré de groupe principal est utilisé chaque fois que des applications s’exécutant en tant que service système ou réseau accèdent à des ressources sur le réseau. Le nom du compte de service administré de groupe devient le nom du conteneur sur le réseau, quel que soit le nom d’hôte attribué au conteneur. Vous pouvez également configurer des conteneurs avec des comptes de service administré de groupe supplémentaires si vous souhaitez exécuter un service ou une application dans le conteneur sous une identité différente de celle du compte d’ordinateur de conteneur.

Lorsque vous créez un compte de service administré de groupe, vous créez également une identité partagée que vous pouvez utiliser simultanément sur de nombreux ordinateurs différents. L’accès au mot de passe du compte de service administré de groupe est protégé par une liste de contrôle d’accès Active Directory. Nous vous recommandons de créer un groupe de sécurité pour chaque compte de service administré de groupe, et d’ajouter les hôtes de conteneur appropriés au groupe de sécurité pour limiter l’accès au mot de passe.

Enfin, étant donné que les conteneurs n’inscrivent pas automatiquement de noms de principal de service, vous devez créer manuellement au moins un nom de principal de service d’hôte pour votre compte de service administré de groupe.

En règle générale, l’hôte ou le nom de principal de service HTTP sont inscrits sous le même nom que le compte de service administré de groupe, mais il se peut que vous deviez utiliser un nom de service différent si les clients accèdent à l’application en conteneur derrière un équilibreur de charge ou un nom DNS différent du nom de compte de service administré de groupe.

Par exemple, si le compte de service administré de groupe est nommé « WebApp01 », mais que vos utilisateurs accèdent au site via la page mysite.contoso.com, vous devez inscrire un nom de principal de service http/mysite.contoso.com sur le compte de service administré de groupe.

Certaines applications peuvent nécessiter des noms de principal de service supplémentaires pour leurs protocoles spécifiques. Par exemple, SQL Server requiert le nom de principal de service MSSQLSvc/hostname.

Le tableau suivant répertorie les attributs requis pour la création d’un compte de service administré de groupe.

Propriété de compte de service administré de groupe	Valeur requise	Exemple
Nom	N’importe quel nom de compte valide.	`WebApp01`
DNSHostName	Nom de domaine ajouté au nom du compte.	`WebApp01.contoso.com`
ServicePrincipalNames	Définissez au moins le nom de principal de service de l’hôte, puis ajoutez d’autres protocoles si nécessaire.	`'host/WebApp01', 'host/WebApp01.contoso.com'`
PrincipalsAllowedToRetrieveManagedPassword	Groupe de sécurité contenant vos hôtes de conteneur.	`WebApp01Hosts`

Une fois que vous avez choisi le nom de votre compte de service administré de groupe, exécutez les cmdlets suivantes dans PowerShell pour créer le groupe de sécurité et le compte de service administré de groupe.

Conseil

Vous devez utiliser un compte appartenant au groupe de sécurité Admins du domaine ou auquel est déléguée l’autorisation Créer des objets msDS-GroupManagedServiceAccount nécessaire pour exécuter les commandes suivantes. La cmdlet New-ADServiceAccount fait partie des outils PowerShell Active Directory appelés Outils d’administration de serveur distant.

Nous vous recommandons de créer des comptes gMSA distincts pour vos environnements de développement, de test et de production.

Cas d’usage pour la création d’un compte gMSA pour des hôtes de conteneurs joints à un domaine

# 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$"

Cas d’usage pour la création d’un compte gMSA pour des hôtes de conteneurs non joints à un domaine

Lors de l’utilisation de gMSA pour des conteneurs avec des hôtes non joints à un domaine, au lieu d’ajouter des hôtes de conteneur au groupe de sécurité WebApp01Hosts, créez et ajoutez un compte d’utilisateur standard.

# 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"

Préparer votre hôte de conteneur

Cas d’usage pour la préparation de l’hôte de conteneur pour un hôte de conteneur joint à un domaine

Chaque hôte de conteneur appelé à exécuter un conteneur Windows avec un compte de service administré de groupe doit être joint à un domaine et disposer de l’accès nécessaire pour récupérer le mot de passe du compte de service administré de groupe.

Joignez votre ordinateur à un domaine Active Directory.
Assurez-vous que votre hôte appartient au groupe de sécurité contrôlant l’accès au mot de passe du compte de service administré de groupe.
Redémarrez l’ordinateur pour obtenir sa nouvelle appartenance de groupe.
Configurez Docker Desktop pour Windows 10 ou Docker pour Windows Server.

(Recommandé) Vérifiez que l’hôte peut utiliser le compte de service administré de groupe en exécutant la commande test-ADServiceAccount. Si la commande retourne False, suivez les Instructions de résolution des problèmes.

# 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

Cas d’usage pour la préparation de l’hôte de conteneur pour un hôte de conteneur non joint à un domaine

Quand vous utilisez gMSA pour les conteneurs Windows sur des hôtes de conteneur non joints à un domaine, chaque hôte de conteneur doit avoir un plug-in pour ccg.exe installé, qui sera utilisé pour récupérer le compte d’utilisateur portable et les informations d’identification spécifiées à l’étape précédente. Les plug-ins sont propres au magasin de secrets utilisé pour protéger les informations d’identification du compte d’utilisateur portable. Par exemple, des plug-ins différents seraient nécessaires pour stocker les informations d’identification du compte dans Azure Key Vault et dans un magasin de secrets Kubernetes.

Windows n’offre actuellement pas de plug-in par défaut intégré. Les instructions d’installation pour les plug-ins sont spécifiques à l’implémentation. Pour plus d’informations sur la création et l’inscription de plug-ins pour ccg.exe, consultez Interface ICcgDomainAuthCredentials.

Créer une spécification d’informations d’identification

Un fichier de spécification d’informations d’identification est un document JSON contenant des métadonnées relatives aux comptes de service administré de groupe que vous souhaitez qu’un conteneur utilise. En gardant la configuration de l’identité séparée de l’image conteneur, vous pouvez changer le gMSA utilisé par le conteneur en remplaçant simplement le fichier de spécification d’informations d’identification : aucune modification du code n’est nécessaire.

Le fichier de spécification d’informations d’identification est créé en utilisant le module PowerShell CredentialSpec sur une machine jointe à un domaine. Une fois que vous avez créé le fichier, vous pouvez le copier sur d’autres hôtes de conteneur ou sur votre orchestrateur de conteneurs. Le fichier de spécification d’informations d’identification ne contient pas de secret tel que le mot de passe du compte de service administré de groupe, car l’hôte de conteneur récupère le compte de service administré de groupe au nom du conteneur.

Docker s’attend à trouver le fichier de spécification d’informations d’identification sous le sous-répertoire CredentialSpecs du répertoire de données Docker. Dans une installation par défaut, vous trouverez ce dossier à l’adresse C:\ProgramData\Docker\CredentialSpecs.

Pour créer un fichier de spécification d’informations d’identification sur votre hôte de conteneur :

Installer les outils PowerShell Active Directory nommés Outils d’administration de serveur distant
- Pour Windows Server, exécutez la commande install-WindowsFeature RSAT-AD-PowerShell.
- Pour Windows 10, version 1809 ou ultérieure, exécutez la commande Add-WindowsCapability -Online -Name ’Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0’ .
- Pour les versions antérieures de Windows 10, consultez la page https://aka.ms/rsat.
Exécutez la cmdlet suivante pour installer la dernière version du module PowerShell CredentialSpec :
```
Install-Module CredentialSpec
```
Si vous n’avez pas accès à Internet sur votre hôte de conteneur, exécutez Save-Module CredentialSpec sur une machine connectée à Internet, puis copiez le dossier du module dans C:\Program Files\WindowsPowerShell\Modules ou à un autre emplacement dans $env:PSModulePath sur l’hôte de conteneur.
Exécutez la cmdlet suivante pour créer le fichier de spécification d’informations d’identification :
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
Par défaut, l’applet de commande va créer une spécification d’informations d’identification en utilisant le nom du gMSA fourni comme compte d’ordinateur pour le conteneur. Le fichier est enregistré dans le répertoire CredentialSpecs de Docker en utilisant comme nom de fichier le domaine du compte de service administré de groupe et le nom du compte.

Si vous souhaitez enregistrer le fichier dans un autre répertoire, utilisez le paramètre -Path :
```
New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
```
Vous pouvez également créer une spécification d’informations d’identification qui inclut des comptes de service administré de groupe supplémentaires si vous exécutez un service ou un processus en tant que compte de service administré de groupe secondaire dans le conteneur. Pour ce faire, utilisez le paramètre -AdditionalAccounts :
```
New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
```
Pour obtenir la liste complète des paramètres pris en charge, exécutez la commande Get-Help New-CredentialSpec -Full.
Pour afficher la liste de toutes les spécifications d’informations d’identification avec leur chemin d’accès complet, utilisez la cmdlet suivante :
```
Get-CredentialSpec
```

Voici un exemple de spécification d’informations d’identification :

{
    "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"
            }
        ]
    }
}

Configuration de spécifications d’informations d’identification supplémentaires pour un cas d’usage avec un hôte de conteneur non joint à un domaine

Quand vous utilisez gMSA avec des hôtes de conteneur non joints à un domaine, les informations relatives au plug-in de ccg.exe que vous allez utiliser doivent être ajoutées aux spécifications d’informations d’identification. Celles-ci seront ajoutées à une section de la spécification d’informations d’identification appelée HostAccountConfig. La section HostAccountConfig contient trois champs qui doivent être renseignés :

PortableCcgVersion : Ce champ doit être défini sur « 1 ».
PluginGUID : CLSID COM pour le plug-in ccg.exe. Ceci est unique pour le plug-in utilisé.
PluginInput : Entrée spécifique au plug-in permettant de récupérer les informations du compte d’utilisateur auprès du magasin de secrets.

Voici un exemple de spécification d’informations d’identification avec la section HostAccountConfig ajoutée :

{
    "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>"
        }
    }
}

Étapes suivantes

Maintenant que vous avez configuré votre compte de service administré de groupe, vous pouvez l’utiliser pour :

Si vous rencontrez des problèmes lors de la configuration, vous trouverez peut-être des solutions dans notre Guide de résolution des problèmes.

Ressources supplémentaires

Pour en savoir plus sur les comptes de service administré de groupe, consultez la Vue d’ensemble des comptes de service administré de groupe.