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.
Configurar gMSA para pods y contenedores de Windows
¿Qué es una cuenta gMSA?
Las aplicaciones basadas en Windows, como las aplicaciones.NET, suelen utilizar Active Directory como proveedor de identidad y authorization/authentication utilizan el protocolo NTLM o Kerberos.
Un servidor de aplicaciones para intercambiar tickets de Kerberos con Active Directory debe estar unido a un dominio. Los contenedores de Windows no admiten la unión de dominios y no tendrían mucho sentido, ya que los contenedores son recursos efímeros, lo que supone una carga para el conjunto de RID de Active Directory.
Sin embargo, los administradores pueden aprovechar las cuentas de Active Directory de gMSA
Caso de uso de contenedor de Windows y gMSA
Las aplicaciones que utilizan la autenticación de Windows y se ejecutan como contenedores de Windows se benefician de la 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 para que sea compatible con la integración de gMSA:
En esta configuración, el nodo de trabajo de Windows está unido a un dominio en el dominio de Active Directory y la cuenta de equipo AD de los nodos de trabajo de Windows se utiliza para autenticarse en Active Directory y recuperar la identidad gMSA que se utilizará con el pod.
En el enfoque de unión a un dominio, puede administrar y reforzar fácilmente los nodos de trabajo de Windows mediante el Active Directory existente GPOs; sin embargo, esto genera una sobrecarga operativa adicional y demoras cuando los nodos de trabajo de Windows se unen 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 sobre cómo implementar el enfoque de nodos de trabajo de Windows unidos a un dominio: step-by-step
Autenticación de Windows en los pods de Windows de Amazon EKS
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» (usuario/contraseña) para autenticarse en Active Directory y recuperar la identidad gMSA que se utilizará con el pod.
La identidad portátil es un usuario de Active Directory; la identidad (usuario/contraseña) se almacena en el almacén de parámetros de AWS Secrets Manager o AWS System Manager, y se utilizará un complemento desarrollado por AWS llamado 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 utilizar gMSA y de reducir la sobrecarga operativa para los administradores de Active Directory.
En la siguiente entrada del blog, encontrará información detallada step-by-step 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
A pesar de que el pod puede utilizar una cuenta gMSA, también es necesario configurar la aplicación o el servicio en consecuencia para admitir la autenticación de Windows. Por ejemplo, para configurar Microsoft IIS para que admita la autenticación de Windows, debe prepararlo mediante 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'
