Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Configure gMSA para contenedores y pods de Windows
¿Qué es una cuenta gMSA
Windows-based las aplicaciones, como las aplicaciones.NET, suelen utilizar Active Directory como proveedor de identidad, siempre que authorization/authentication utilicen el protocolo NTLM o Kerberos.
Un servidor de aplicaciones para intercambiar tickets de Kerberos con Active Directory requiere estar unido a un dominio. Los contenedores de Windows no admiten uniones de dominios y no tendría mucho sentido, ya que son recursos efímeros y suponen una carga para el conjunto de RID de Active Directory.
Sin embargo, los administradores pueden aprovechar las cuentas de Active Directory de
Caso de uso de contenedores de Windows y gMSA
Las aplicaciones que utilizan la autenticación de Windows y se ejecutan como contenedores de Windows se benefician de gMSA, ya que el nodo de Windows se utiliza para intercambiar el vale de Kerberos en nombre del contenedor. Hay dos opciones disponibles para configurar el nodo de trabajo de Windows de modo que permita la integración de gMSA:
1 - Nodos de trabajo de Windows Domain-joined
En esta configuración, el nodo de trabajo de Windows está unido al dominio de Active Directory y la cuenta de computadora AD de los nodos de trabajo de Windows se usa para autenticarse en Active Directory y recuperar la identidad de gMSA que se utilizará con el pod.
En el enfoque unido a un dominio, puede administrar y reforzar fácilmente los nodos de trabajo de Windows mediante los GPO de Active Directory existentes; sin embargo, genera una sobrecarga operativa adicional y retrasos durante la incorporación de los nodos de trabajo de Windows al clúster de Kubernetes, ya que requiere reinicios adicionales durante el inicio del nodo y la limpieza del garaje de Active Directory una vez que el clúster de Kubernetes termina los nodos.
En la siguiente entrada del blog, encontrará información detallada paso a paso sobre cómo implementar el enfoque de nodos de trabajo de Windows: Domain-joined
Autenticación de Windows en los pods de Windows de Amazon EKS
2: Nodos de trabajo de Windows sin dominio
En esta configuración, el nodo de trabajo de Windows no está unido al dominio de Active Directory y se utiliza una identidad «portátil» (user/password) para autenticarse en Active Directory y recuperar la identidad de gMSA que se utilizará con el pod.
La identidad portátil es la de un usuario de Active Directory; la identidad (user/password) se almacena en el almacén de parámetros de AWS Secrets Manager o AWS System Manager, y se utilizará un AWS-developed complemento denominado ccg_plugin para recuperar esta identidad del almacén de parámetros de AWS Secrets Manager o AWS System Manager y pasarla a containerd para recuperar la identidad de gMSA y ponerla a disposición del pod.
Con este enfoque sin dominio, puede beneficiarse de no tener ninguna interacción con Active Directory durante el inicio del nodo de trabajo de Windows al usar gMSA y de reducir la sobrecarga operativa para los administradores de Active Directory.
En la siguiente entrada del blog, encontrará información detallada sobre cómo implementar el enfoque de nodos de trabajo de Windows sin dominio:
Autenticación de Windows sin dominio para los pods de Windows de Amazon EKS
Notas importantes
A pesar de que el pod puede usar una cuenta de gMSA, también es necesario configurar la aplicación o el servicio en consecuencia para que sea compatible con la autenticación de Windows. Por ejemplo, para configurar Microsoft IIS de forma que sea compatible con la autenticación de Windows, debe prepararlo mediante un dockerfile:
RUN Install-WindowsFeature -Name Web-Windows-Auth -IncludeAllSubFeature RUN Import-Module WebAdministration; Set-ItemProperty 'IIS:\AppPools\SiteName' -name processModel.identityType -value 2 RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/anonymousAuthentication' -Name Enabled -Value False -PSPath 'IIS:\' -Location 'SiteName' RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name Enabled -Value True -PSPath 'IIS:\' -Location 'SiteName'
