Creación de gMSA para contenedores de Windows

Artículo
03/21/2023

Se aplica a: Windows Server 2022, Windows Server 2019

Las redes basadas en Windows suelen usar Active Directory (AD) para facilitar la autenticación y autorización entre usuarios, equipos y otros recursos de red. A menudo, los desarrolladores de aplicaciones empresariales diseñan sus aplicaciones para que estén integradas en AD y se ejecuten en servidores unidos a un dominio para aprovechar la autenticación integrada de Windows, lo que facilita que los usuarios y otros servicios inicien sesión de forma automática y transparente en la aplicación con sus identidades. En este artículo se explica cómo empezar a usar las cuentas de servicio administradas de grupo de Active Directory con contenedores de Windows.

Aunque los contenedores de Windows no pueden unirse a un dominio, pueden seguir usando las identidades de dominio de Active Directory para admitir varios escenarios de autenticación. Para ello, puede configurar un contenedor de Windows para que se ejecute con una cuenta de servicio administrada de grupo (gMSA), que es un tipo especial de cuenta de servicio que se presentó en Windows Server 2012, y está diseñada para permitir que varios equipos compartan una identidad sin necesidad de conocer su contraseña. Los contenedores de Windows no pueden unirse a un dominio, pero muchas aplicaciones de Windows que se ejecutan en contenedores de Windows siguen necesitando autenticación de AD. Para usar la autenticación de AD, puede configurar un contenedor de Windows para que se ejecute con una cuenta de servicio administrada de grupo (gMSA).

Cuando las cuentas gMSA para los contenedores de Windows se introdujeron inicialmente, era necesario unir el host del contenedor a un dominio, lo que creaba una gran sobrecarga para los usuarios, que debían unir manualmente los nodos de trabajo de Windows a un dominio. Esta limitación se ha solucionado con la compatibilidad de gMSA con los contenedores de Windows para los hosts de contenedor que no están unidos a ningún dominio. La funcionalidad original de gMSA para usar un host de contenedor unido a un dominio seguirá siendo compatible.

Entre las mejoras de gMSA al usar un host de contenedor no unido a ningún dominio se incluyen:

Se ha eliminado el requisito de unir manualmente los nodos de trabajo de Windows a un dominio, ya que generaba una gran sobrecarga para los usuarios. En escenarios de escalado, el uso de un host de contenedor no unido a un dominio simplifica el proceso.
En escenarios de actualización gradual, los usuarios ya no tienen que volver a unir el nodo a un dominio.
Un proceso más sencillo para administrar la máquina de nodos de trabajo consiste en recuperar las contraseñas de las cuentas del servicio gMSA.
La configuración de gMSA con Kubernetes es un proceso de un extremo a otro menos complicado.

Nota:

Para obtener información sobre cómo la comunidad de Kubernetes usa gMSA con contenedores de Windows, consulte Configuración de gMSA.

Arquitectura y mejoras de gMSA

Para abordar las limitaciones de la implementación inicial de gMSA para los contenedores de Windows, la nueva compatibilidad de gMSA con los hosts de contenedores no unidos a ningún dominio utiliza una identidad de usuario portátil en lugar de una cuenta del equipo host para recuperar las credenciales de gMSA. Por lo tanto, ya no es necesario unir manualmente nodos de trabajo de Windows a un dominio, aunque todavía se admite. La identidad o las credenciales del usuario se guardan en un almacén de secretos accesible para el host de contenedor (por ejemplo, como un secreto de Kubernetes) en el que los usuarios autenticados pueden recuperarlo.

Diagram of group Managed Service Accounts version two

La compatibilidad de gMSA con hosts de contenedor que no están unidos a ningún dominio aporta la flexibilidad de crear contenedores con gMSA sin unir el nodo de host al dominio. A partir de Windows Server 2019, se puede usar ccg.exe que habilita un mecanismo complementario para recuperar las credenciales de gMSA de Active Directory. Puede usar esa identidad para iniciar el contenedor. Para obtener más información sobre el mecanismo de este complemento, consulte Interfaz ICcgDomainAuthCredentials.

Nota

En Azure Kubernetes Service en Azure Stack HCI, puede usar el complemento para comunicarse de ccg.exe a AD y, a continuación, recuperar las credenciales de gMSA. Para obtener más información, consulte Configuración de la cuenta de servicio administrada de grupo con AKS en Azure Stack HCI.

Vea el diagrama a continuación para seguir los pasos del proceso de Container Credential Guard:

Con un archivo CredSpec como entrada, el proceso ccg.exe se inicia en el host del nodo.
ccg.exe usa la información del archivo CredSpec para iniciar un complemento y, a continuación, recupera las credenciales de la cuenta en el almacén de secretos asociado al complemento.
ccg.exe usa las credenciales de la cuenta recuperadas para recuperar la contraseña de gMSA de AD.
ccg.exe pone la contraseña de gMSA a disposición de un contenedor que ha solicitado las credenciales.
El contenedor se autentica en el controlador de dominio mediante la contraseña de gMSA para obtener un vale de concesión de vales (TGT) de Kerberos.
Las aplicaciones que se ejecutan como servicio de red o sistema local en el contenedor ahora pueden autenticarse y acceder a recursos de dominio, como la cuenta gMSA.

Requisitos previos

Para ejecutar un contenedor de Windows con una cuenta de servicio administrada de grupo, necesitarás lo siguiente:

Un dominio de Active Directory con al menos un controlador de dominio que ejecute Windows Server 2012 o posterior. No hay ningún requisito de nivel funcional de bosque o dominio para usar las gMSA, pero las contraseñas de gMSA solo pueden distribuirse mediante controladores de dominio que ejecuten Windows Server 2012 o posterior. Para más información, consulta Requisitos de Active Directory para gMSA.
Permiso para crear una cuenta gMSA. Para crear una cuenta gMSA, debes ser administrador de dominio o usar una cuenta que tenga delegado el permiso Crear objetos msDS-GroupManagedServiceAccount.
Acceso a Internet para descargar el módulo de CredentialSpec de PowerShell. Si trabajas en un entorno desconectado, puedes guardar el módulo en un equipo con acceso a Internet y copiarlo en la máquina de desarrollo o en el host de contenedor.

Preparación única de Active Directory

Si aún no has creado una gMSA en el dominio, deberás generar la clave raíz del servicio de distribución de claves (KDS). KDS es responsable de crear, rotar y liberar la contraseña de gMSA para los hosts autorizados. Cuando un host de contenedor necesita usar la gMSA para ejecutar un contenedor, se pondrá en contacto con KDS para recuperar la contraseña actual.

Para comprobar si ya se ha creado la clave raíz de KDS, ejecuta el siguiente cmdlet de PowerShell como administrador de dominio en un controlador de dominio o miembro de dominio con las herramientas de PowerShell de AD instaladas:

Get-KdsRootKey

Si el comando devuelve un identificador de clave, estás listo y puedes ir directamente a la sección Creación de una cuenta de servicio administrada de grupo. De lo contrario, continúe para crear la clave raíz de KDS.

Importante

Solo debe crear una clave raíz de KDS por bosque. Si se crean varias claves raíz de KDS, se empezarán a producir errores en la gMSA después de cambiar su contraseña.

En un entorno de producción o en un entorno de prueba con varios controladores de dominio, ejecuta el siguiente cmdlet en PowerShell como administrador de dominio para crear la clave raíz de KDS.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Aunque el comando implica que la clave entrará en vigor de inmediato, tendrás que esperar 10 horas para que la clave raíz de KDS se replique y esté disponible para su uso en todos los controladores de dominio.

Si solo tienes un controlador de dominio en el dominio, puedes acelerar el proceso estableciendo la clave para que entre en vigor 10 horas antes.

Importante

No uses esta técnica en un entorno de producción.

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

Creación de una cuenta de servicio administrada de grupo

Cada contenedor que use la autenticación integrada de Windows necesita al menos una gMSA. La gMSA principal se usa siempre que las aplicaciones que se ejecutan como sistema o servicio de red acceden a los recursos de la red. El nombre de la gMSA se convertirá en el nombre del contenedor en la red, independientemente del nombre de host que se haya asignado al contenedor. Los contenedores también se pueden configurar con gMSA adicionales, en caso de que quieras ejecutar un servicio o una aplicación en el contenedor con una identidad diferente de la cuenta de equipo del contenedor.

Cuando creas una gMSA, también creas una identidad compartida que se puede usar simultáneamente en muchas máquinas diferentes. El acceso a la contraseña de gMSA está protegido por una lista de control de acceso de Active Directory. Se recomienda crear un grupo de seguridad para cada cuenta gMSA y agregar los hosts de contenedor correspondientes al grupo de seguridad para limitar el acceso a la contraseña.

Por último, dado que los contenedores no registran automáticamente ningún nombre de entidad de seguridad de servicio (SPN), tendrás que crear manualmente al menos un SPN de host para la cuenta gMSA.

Normalmente, el SPN de host o http se registra con el mismo nombre que la cuenta gMSA, pero puede que tengas que usar otro nombre de servicio si los clientes acceden a la aplicación en contenedores desde detrás de un equilibrador de carga, o un nombre DNS diferente del nombre de la gMSA.

Por ejemplo, si la cuenta gMSA se denomina "WebApp01", pero los usuarios acceden al sitio en mysite.contoso.com, debes registrar un SPN http/mysite.contoso.com en la cuenta gMSA.

Algunas aplicaciones pueden requerir SPN adicionales para sus protocolos exclusivos. Por ejemplo, SQL Server requiere el SPN MSSQLSvc/hostname.

En la tabla siguiente se enumeran los atributos necesarios para crear una gMSA.

Propiedad de gMSA	Valor obligatorio	Ejemplo
Nombre	Cualquier nombre de cuenta válido.	`WebApp01`
DnsHostName	Nombre de dominio anexado al nombre de la cuenta.	`WebApp01.contoso.com`
ServicePrincipalNames	Establece al menos el SPN del host, agrega otros protocolos según sea necesario.	`'host/WebApp01', 'host/WebApp01.contoso.com'`
PrincipalsAllowedToRetrieveManagedPassword	El grupo de seguridad que contiene los hosts de contenedor.	`WebApp01Hosts`

Una vez que hayas decidido el nombre de la gMSA, ejecuta los siguientes cmdlets en PowerShell para crear el grupo de seguridad y la gMSA.

Sugerencia

Tendrás que usar una cuenta que pertenezca al grupo de seguridad Administradores de dominio o a la que se le haya delegado el permiso Crear objetos msDS-GroupManagedServiceAccount para ejecutar los siguientes comandos. El cmdlet New-ADServiceAccount forma parte de las herramientas de PowerShell de AD de Herramientas de administración remota del servidor.

Le recomendamos crear cuentas gMSA independientes para los entornos de desarrollo, pruebas y producción.

Caso de uso para crear una cuenta de gMSA para hosts de contenedor unidos a un dominio

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

Caso de uso para crear una cuenta de gMSA para hosts de contenedor que no estén unidos a un dominio

Al usar gMSA para contenedores con hosts que no están unidos a ningún dominio, en lugar de agregar hosts de contenedor al grupo de seguridad WebApp01Hosts, cree y agregue una cuenta de usuario estándar.

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

Preparación del host de contenedor

Caso de uso para preparar el host de contenedor para un host de contenedor unido a un dominio

Cada host de contenedor que ejecutará un contenedor de Windows con una gMSA debe estar unido a un dominio y tener acceso para recuperar la contraseña de la gMSA.

Une tu equipo a tu dominio de Active Directory.
Asegúrate de que el host pertenezca al grupo de seguridad que controla el acceso a la contraseña de la gMSA.
Reinicie el equipo para obtener su nueva pertenencia al grupo.
Configura Docker Desktop on Windows 10 o Docker on Windows Server.

(Recomendado) Para verificar que el host pueda usar la cuenta gMSA, ejecuta Test-ADServiceAccount. Si el comando devuelve False, sigue las instrucciones de solución de problemas.

# 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

Caso de uso para preparar el host de contenedor para un host de contenedor que no esté unido a un dominio

Cuando se usa gMSA para contenedores de Windows en hosts de contenedor que no están unidos a ningún dominio, cada host de contenedor debe tener instalado un complemento para ccg.exe que se usará para recuperar la cuenta de usuario portátil y las credenciales especificadas en el paso anterior. Los complementos son exclusivos del almacén de secretos que se usa para proteger las credenciales de la cuenta de usuario portátil. Por ejemplo, se necesitan complementos diferentes para almacenar las credenciales de la cuenta en Azure Key Vault en un almacén de secretos de Kubernetes.

Actualmente, Windows no ofrece un complemento predeterminado integrado. Las instrucciones de instalación de los complementos serán específicas de la implementación. Para obtener más información sobre cómo crear y registrar complementos para ccg.exe, consulte Interfaz ICcgDomainAuthCredentials.

Creación de una especificación de credenciales

Un archivo de especificación de credenciales es un documento JSON que contiene metadatos sobre las cuentas gMSA que quieres que use un contenedor. Al mantener la configuración de identidad separada de la imagen del contenedor, puede cambiar la cuenta gMSA que usa el contenedor simplemente intercambiando el archivo de especificación de credenciales, sin necesidad de realizar cambios en el código.

El archivo de especificación de credenciales se crea mediante el módulo CredentialSpec de PowerShell en una máquina unida a un dominio. Una vez que haya creado el archivo, puede copiarlo en otros hosts de contenedor o en el orquestador de contenedores. El archivo de especificación de credenciales no contiene ningún secreto, como la contraseña de la gMSA, ya que el host de contenedor recupera la gMSA en nombre del contenedor.

Docker espera encontrar el archivo de especificación de credenciales en el directorio CredentialSpecs en el directorio de datos de Docker. En una instalación predeterminada, encontrarás esta carpeta en C:\ProgramData\Docker\CredentialSpecs.

Para crear un archivo de especificación de credenciales en el host de contenedor:

Instala las herramientas de PowerShell de AD desde RSAT.
- En Windows Server, ejecuta Install-WindowsFeature RSAT-AD-PowerShell.
- En Windows 10, versión 1809 o posterior, ejecuta Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0' .
- Para versiones anteriores de Windows 10, consulta https://aka.ms/rsat.
Ejecuta el siguiente cmdlet para instalar la versión más reciente del módulo CredentialSpec de PowerShell:
```
Install-Module CredentialSpec
```
Si no tiene acceso a Internet en el host de contenedor, ejecute Save-Module CredentialSpec en una máquina conectada a Internet y copie la carpeta del módulo en C:\Program Files\WindowsPowerShell\Modules u otra ubicación en $env:PSModulePath en el host de contenedor.
Ejecuta el siguiente cmdlet para crear el nuevo archivo de especificación de credenciales:
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
De forma predeterminada, el cmdlet creará una especificación de credenciales usando el nombre de la cuenta gMSA proporcionado como cuenta de equipo para el contenedor. El archivo se guardará en el directorio CredentialSpecs de Docker con el dominio y el nombre de cuenta de gMSA para el nombre de archivo.

Si quieres guardar el archivo en otro directorio, usa el parámetro -Path:
```
New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
```
También puede crear una especificación de credenciales que incluya cuentas gMSA adicionales si estás ejecutando un servicio o proceso como gMSA secundaria en el contenedor. Para ello, usa el parámetro -AdditionalAccounts:
```
New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
```
Para obtener una lista completa de los parámetros admitidos, ejecuta Get-Help New-CredentialSpec -Full.
Puedes mostrar una lista de todas las especificaciones de credenciales y su ruta de acceso completa con el siguiente cmdlet:
```
Get-CredentialSpec
```

Este es un ejemplo de una especificación de credenciales:

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

Configuración de especificaciones de credenciales adicionales para el caso de uso del host de contenedor no unido a ningún dominio

Al usar gMSA con hosts de contenedor que no están unidos a ningún dominio, es necesario agregar información sobre el complemento ccg.exe que va a usar a la especificación de credenciales. Esto se agregará a una sección de la especificación de credenciales denominada HostAccountConfig. La sección HostAccountConfig tiene tres campos que deben rellenarse:

PortableCcgVersion: debe establecerse en "1".
PluginGUID: COM CLSID para el complemento ccg.exe. Es único para el complemento que se usa.
PluginInput: entrada específica del complemento para recuperar la información de la cuenta de usuario del almacén de secretos.

Este es un ejemplo de una especificación de credenciales con la sección HostAccountConfig agregada:

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

Pasos siguientes

Ahora que has configurado la cuenta gMSA, puedes usarla para lo siguiente:

Si tienes problemas durante la instalación, consulta nuestra guía de solución de problemas para ver las posibles soluciones.

Recursos adicionales

Para más información sobre las gMSA, consulta la Información general sobre las cuentas de servicio administradas de grupo.

Compartir a través de

Creación de gMSA para contenedores de Windows

Arquitectura y mejoras de gMSA

Requisitos previos

Preparación única de Active Directory

Creación de una cuenta de servicio administrada de grupo

Caso de uso para crear una cuenta de gMSA para hosts de contenedor unidos a un dominio

Caso de uso para crear una cuenta de gMSA para hosts de contenedor que no estén unidos a un dominio

Preparación del host de contenedor

Caso de uso para preparar el host de contenedor para un host de contenedor unido a un dominio

Caso de uso para preparar el host de contenedor para un host de contenedor que no esté unido a un dominio

Creación de una especificación de credenciales

Configuración de especificaciones de credenciales adicionales para el caso de uso del host de contenedor no unido a ningún dominio

Pasos siguientes

Recursos adicionales

Comentarios

Recursos adicionales