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

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 que no está 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 que habilita un mecanismo complementario para recuperar 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 en la arquitectura gMSA para contenedores con un host no unido a un dominio, por lo que los usuarios ahora pueden usar gMSA con hosts separados de un dominio. Entre otras mejoras de gMSA, se incluyen las siguientes:

  • Eliminación del requisito de unir manualmente nodos de trabajo de Windows a un dominio, que suponía una importante sobrecarga. En escenarios de escalado, esto simplificará 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 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 de gMSA, es necesario ser administrador de dominio o usar una cuenta que tenga asignado el permiso 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 cuenta de 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. Esta cuenta de usuario o contraseña se guardará como un secreto de Kubernetes y se usará 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 del 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, además de habilitar el control de acceso basado en roles (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. Proporcione los datos de configuración siguientes 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 add-AksHciGMSACredentialSpec de PowerShell 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 se encuentre en el contenedor, ejecute lo siguiente:

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