Compartir a través de

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

  • Artículo

Se aplica a: AKS en Azure Stack HCI 22H2, 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 pueden estar unidos a un dominio, pero muchas aplicaciones de Windows que se ejecutan en contenedores de Windows siguen necesitando la 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, ya no es necesario unir manualmente los 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 unido a un dominio, por lo que los usuarios ahora pueden usar gMSA con hosts no unidos a un dominio. Otras mejoras de gMSA incluyen las siguientes características:

  • Eliminación del requisito de unir manualmente nodos de trabajo de Windows a un dominio, que suponía una importante sobrecarga. Para escenarios de escalado, esto 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 de servicio gMSA.
  • Un proceso integral menos complicado para configurar 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 hay requisitos de nivel funcional de bosque o dominio para usar gMSA, pero solo los controladores de dominio que ejecutan Windows Server 2012 o versiones posteriores 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 asegurarse de que la autenticación de AD y gMSA funcionan, asegúrese de que los nodos del clúster de Azure Stack HCI y Windows Server están configurados para sincronizar la hora 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:

  1. En el controlador de dominio, prepare Active Directory y cree cuenta de gMSA.

  2. Cree una cuenta de usuario de dominio. Estas credenciales de contraseña o cuenta de usuario se guardan como un secreto de Kubernetes y se usan para recuperar la contraseña de gMSA.

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

     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.

Configuración de 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 Azure Stack HCI y Windows Server, hay otros pasos de configuración que sí lo son. 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 se han creado para ayudar a simplificar el proceso de configuración.

Antes de completar los pasos siguientes, asegúrese de que el módulo aksHci de PowerShell está instalado y kubectl puede conectarse al clúster.

  1. Para instalar el webhook, ejecute el siguiente comando Install-AksHciGmsaWebhook de PowerShell:

    Install-AksHciGMSAWebhook -Name <cluster name>

    Para comprobar que el pod de webhook se está ejecutando correctamente, utilice el comando siguiente:

    kubectl get pods -n kube-system | findstr gmsa

    Debería ver un pod con el prefijo gmsa-webhook que se está ejecutando.

  2. 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.

  3. Use el cmdlet de PowerShell Add-AksHciGMSACredentialSpec para crear la CRD de gMSA, habilitar el control de acceso basado en rol (RBAC) y, a continuación, asignar el rol a las cuentas de servicio para usar un archivo de especificación de credenciales gMSA específico. 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.

  1. Agregue la cuenta de servicio:

    serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

  2. Agregue el objeto de especificación de credenciales:

    securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

  3. 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

  4. 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:

  1. Obtenga el id. de contenedor para la implementación mediante la ejecución del siguiente comando:

    kubectl get pods

  2. Abra PowerShell y ejecute el comando siguiente:

    kubectl exec -it <container id> powershell

  3. 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 autentica el equipo y que existe un canal seguro entre el equipo cliente y el controlador de dominio.

  4. 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 Install-Uninstall-AksHciGMSAWebhook de PowerShell:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Pasos siguientes