Configuración de cuentas de servicio administradas de grupo (gMSA) para contenedores de Windows con Azure Kubernetes Service en Windows Server

Se aplica a: AKS en Windows Server

Para usar la autenticación de AD, puede configurar cuentas de servicio administradas de grupo (gMSA) para contenedores Windows para que se ejecuten con un host que no está unido a un dominio. Una cuenta de servicio administrada de grupo es un tipo especial de cuenta de servicio que se introdujo en Windows Server 2012 y se ha diseñado para que varios equipos compartan una identidad sin conocer la contraseña. Los contenedores de Windows no se pueden unir a un dominio, pero muchas aplicaciones de Windows que se ejecutan en contenedores de Windows todavía necesitan autenticación de AD.

Nota:

Para información sobre cómo la comunidad de Kubernetes admite el uso de gMSA con contenedores de Windows, consulte Configuración de gMSA.

Arquitectura de gMSA para contenedores con un host no unido a un dominio

gMSA para contenedores con un host no unido a un dominio usa una identidad de usuario portable en lugar de una identidad de host para recuperar las credenciales de gMSA. Por lo tanto, no es necesario unir manualmente nodos de trabajo de Windows a un dominio. La identidad del usuario se guarda como un secreto en Kubernetes. En el diagrama siguiente se muestra el proceso para configurar gMSA para contenedores con un host no unido a un dominio:

Diagrama de la versión dos de las cuentas de servicio administradas de grupo

gMSA para contenedores con un host no unido a un dominio proporciona flexibilidad para crear contenedores con gMSA sin unir el nodo de host al dominio. A partir de Windows Server 2019, se admite ccg.exe, lo que permite que un mecanismo de complemento recupere las credenciales de gMSA de Active Directory. Puede usar esa identidad para iniciar el contenedor. Para más información sobre ccg.exe, vea Interfaz ICcgDomainAuthCredentials.

Comparación de gMSA para contenedores con un host no unido a un dominio y un host unido a un dominio

Cuando se introdujo gMSA, era necesario unir el host contenedor a un dominio, lo que generaba una importante sobrecarga para unir los nodos de trabajo de Windows a un dominio. Esta limitación se ha solucionado con gMSA para contenedores con un host no unido a un dominio, por lo que ahora puede usar gMSA con hosts no unidos a un dominio. Otras mejoras de gMSA incluyen las siguientes características:

Eliminar el requisito de unir manualmente nodos de trabajo de Windows a un dominio. Para escenarios de escalado, esta simplificación ayuda.
En escenarios de actualización gradual, ya no es necesario 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 de servicio gMSA.
Un proceso integral menos complicado para configurar cuentas gMSA con Kubernetes.

Antes de empezar

Para ejecutar un contenedor de Windows con una cuenta de servicio administrada de grupo, necesita los siguientes requisitos previos:

Un dominio de Active Directory con al menos un controlador de dominio que ejecute Windows Server 2012 o posterior. No existen requisitos de nivel funcional de bosque o dominio para utilizar los gMSA, pero solo los controladores de dominio que ejecutan Windows Server 2012 o posterior pueden distribuir contraseñas de gMSA. Para más información, consulta Requisitos de Active Directory para gMSA.
Permiso para crear una cuenta gMSA. Para crear una cuenta de gMSA, debe ser administrador de dominio o usar una cuenta que tenga permisos para crear objetos msDS-GroupManagedServiceAccount .
Acceda a Internet para descargar el módulo 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.
Para garantizar que la autenticación de gMSA y AD funcione, asegúrese de que los nodos del clúster de Windows Server están configurados para sincronizar su tiempo con un controlador de dominio u otro origen de hora. También debe asegurarse de que Hyper-V está configurado para sincronizar la hora con cualquier máquina virtual.

Preparación de la cuenta de gMSA en el controlador de dominio

Siga estos pasos para preparar la gMSA en el controlador de dominio:

En el controlador de dominio, prepare Active Directory y cree la cuenta de gMSA.
Cree una cuenta de usuario de dominio. Guarde esta cuenta de usuario y las credenciales de contraseña como un secreto de Kubernetes. Use estas credenciales para recuperar la contraseña de gMSA.

Para crear una cuenta de gMSA y conceder permiso para leer la contraseña de la cuenta de gMSA creada en el paso 2, ejecute el siguiente comando de PowerShell New-ADServiceAccount :

 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>

Para -PrincipalsAllowedToRetrieveManagedPassword, especifique el nombre de usuario de dominio que creó anteriormente como se muestra en el ejemplo siguiente:

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"

Preparación del archivo JSON de especificación de credenciales de gMSA

Para preparar el archivo JSON de especificación de credenciales de gMSA, siga los pasos sobre la creación de una especificación de credenciales.

Configurar gMSA para pods y contenedores de Windows en el clúster

La comunidad de Kubernetes ya admite los nodos de trabajo de Windows unidos a un dominio para gMSA. Aunque no es necesario unir un dominio a un nodo de trabajo de Windows en AKS en Windows Server, debe completar otros pasos de configuración. Estos pasos incluyen la instalación del webhook, la definición de recursos personalizados (CRD) y la especificación de credenciales y la habilitación del control de acceso basado en rol (rol RBAC). En los pasos siguientes se usan comandos de PowerShell que simplifican el proceso de configuración.

Antes de completar los pasos siguientes, asegúrese de instalar el módulo de AksHci de PowerShell y kubectl puede conectar con su clúster.

Para instalar el webhook, ejecute el siguiente comando Install-AksHciGmsaWebhook de PowerShell:
```
Install-AksHciGMSAWebhook -Name <cluster name>
```
Para validar que el pod de webhook se está ejecutando, ejecute el siguiente comando:
```
kubectl get pods -n kube-system | findstr gmsa
```
Deberías ver un pod con el prefijo gmsa-webhook que se está ejecutando.
Cree el objeto secreto que almacena la credencial de usuario de Active Directory. Complete los siguientes datos de configuración y guarde la configuración en un archivo denominado 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>
```
Después ejecute el siguiente comando para crear el objeto de secreto:
```
kubectl apply -f secret.yaml
```
Nota:

Si crea un secreto en un espacio de nombres distinto al predeterminado, no olvide establecer el espacio de nombres de la implementación en el mismo espacio de nombres.
Utilice el cmdlet de PowerShell Add-AksHciGMSACredentialSpec para crear el CRD de gMSA, activar el control de acceso basado en funciones (RBAC) y, a continuación, asignar la función a las cuentas de servicio para utilizar un archivo específico de especificaciones de credenciales de gMSA. Estos pasos se describen con más detalle en el artículo de Kubernetes Configuración de gMSA para contenedores y pods de Windows.

Use la especificación de credenciales JSON como entrada para el siguiente comando de PowerShell (los parámetros con asteriscos * son obligatorios):
```
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 
```
Para ver un ejemplo, consulte el código siguiente:
```
Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster
```

Implementación de la aplicación

Cree el archivo YAML de implementación con la siguiente configuración de ejemplo. Las entradas necesarias incluyen serviceAccountName, gmsaCredentialSpecName, volumeMounts y dnsconfig.

Agregue la cuenta de servicio:

serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

Agregue el objeto de especificación de credenciales:

securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

Instale el secreto para la implementación:

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

Agregue la dirección IP del controlador de dominio y el nombre de dominio en dnsConfig:

dnsConfig: 
     nameservers:
       - <IP address for domain controller>
     searches: 
       - <domain>

Comprobación del funcionamiento del contenedor con gMSA

Después de implementar el contenedor, compruebe su funcionamiento mediante los pasos siguientes:

Obtenga el id. de contenedor para la implementación mediante la ejecución del siguiente comando:
```
kubectl get pods
```
Abra PowerShell y ejecute el siguiente comando:
```
kubectl exec -it <container id> powershell
```
Una vez que esté en el contenedor, ejecute el siguiente comando:
```
Nltest /parentdomain 
Nltest /sc_verify:<domain> 
```
```
Connection Status = 0 0x0 NERR_Success The command completed successfully. 
```
Esta salida muestra que un controlador de dominio ha autenticado el equipo y existe un canal seguro entre el equipo cliente y el controlador de dominio.
Compruebe si el contenedor puede obtener un servicio de concesión de vales (TGT) de Kerberos válido.
```
klist get krbtgt
```
```
A ticket to krbtgt has been retrieved successfully
```

Limpieza de la configuración de gMSA del clúster

Si necesita limpiar la configuración de gMSA, siga estos pasos de desinstalación.

Desinstalación de la especificación de credenciales

Para desinstalarla, ejecute el siguiente comando Remove-AksHcigmsaCredentialSpec de 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>

Desinstalación de webhook

Para desinstalar el webhook, ejecute el siguiente comando Uninstall-AksHciGMSAWebhook de PowerShell:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Pasos siguientes

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-11-17