Blog de Amazon Web Services (AWS)
Autenticación Windows con Windows Pods en Amazon EKS
Por Marcio Morales, Principal Solutions Architect en Amazon Web Services y
Bruno Gabriel, Ingeniero de soporte en la nube del equipo de implementación.
Según la documentación de Microsoft: las redes basadas en Windows suelen utilizar Active Directory (AD) para facilitar la autenticación y la autorización entre los usuarios, los equipos y otros recursos de red. Los desarrolladores de aplicaciones corporativas generalmente diseñan sus aplicaciones para que se integren con AD y se ejecuten en los servidores asociados al dominio, a fin de aprovechar la autenticación integrada de Windows, que facilita a los usuarios y otros servicios iniciar sesión de forma automática y transparente en la aplicación, utilizando sus propias identidades. Aunque los contenedores Windows no pueden unirse al dominio, sí pueden usar las identidades de dominio de Active Directory para admitir varios escenarios de autenticación.
La autenticación en Windows es un tema que siempre ha aparecido en las reuniones de clientes sobre Windows Containers en Amazon Kubernetes Service (Amazon EKS), desde que Kubernetes comenzó a admitirla como función Alpha en la versión 1.14, y a estabilizarla en la 1.18. En este blog, analizaremos todas las configuraciones necesarias para que funcione, desde CoreDNS y gMSA Webhooks hasta un pod Windows capaz de intercambiar correctamente los tickets de Kerberos.
¿Cómo vamos a lograrlo?
Prerrequisitos:
- Instalar y configurar correctamente la versión más reciente del AWS CLI, eksctl, kubectl y AWS Tools for Powershell en Amazon EC2 Windows.
- Instalar y configurar correctamente el AWS CLI y kubectl en Amazon EC2 Linux
- Que Active Directory Domain Services (AD DS) ya se esté ejecutando en Amazon EC2 o en AWS Managed Microsoft AD
En este blog, realizaremos las siguientes tareas:
- Crear un clúster de EKS con nodos de trabajo autogestionados de Windows.
- Unir el nodo de trabajo Windows a un dominio de Active Directory.
- Crear y configurar las cuentas gMSA en el dominio de Active Directory.
- Instalar el CRD gMSA CredentialSpec.
- Instalar el Windows gMSA Webhook Admission controller.
- Crear recursos de especificaciones de credenciales gMSA (gMSA credential spec).
- Crear un ClusterRole de Kubernetes para cada especificación de credenciales gMSA.
- Asignar el ClusterRole de Kubernetes a una cuenta de servicio específica para la especificación de credenciales gMSA.
- Configurar el conditional forwarder en CoreDNS.
- Configurar la especificación de credenciales gMSA en la especificación del pod Windows.
- Comprobar la autenticación Windows desde el pod Windows.
1. Crear un clúster de EKS con nodos de trabajo de Windows autogestionados
Implemente un clúster de EKS con nodos de trabajo Windows autogestionados. Compruebe que tiene conectividad de red con el dominio de Active Directory y que puede resolver el FQDN del dominio. Si bien puede utilizar su clúster de Amazon EKS existente, en este blog compartiremos una configuración que pueda utilizar para crear su propio clúster de Amazon EKS a través de eksctl.
El siguiente archivo de configuración crea un clúster de EKS con la versión 1.18 de Kubernetes, un nodo de trabajo de Linux administrado y un nodo de trabajo Windows autogestionado, reutiliza un par de claves EC2 existente y asigna políticas de IAM para administrar, monitorear y registrar el nodo de trabajo en un dominio de Active Directory a través de AWS Systems Manager. Puede editar los valores según sea necesario. Tenga en cuenta que no debe eliminar el grupo de nodos de trabajo de Linux administrado, ya que los clústeres mixtos de Amazon EKS requieren al menos 1 nodo de trabajo de Linux.
1.1 Cree un archivo YAML con el siguiente contenido y guárdelo como cluster-spec.yaml.
Nota: Sustituya el nombre del clúster, la región, la zona de disponibilidad, el tipo de instancia, el bloque CIDR de la VPC y el par de claves de las instancias EC2 según sea necesario.
1.2 Para crear el clúster EKS, ejecute el siguiente comando:
1.3 Para administrar el clúster de EKS a través de kubectl, se debe crear un archivo kubeconfig. Ejecute el siguiente comando:
1.4 Compruebe la configuración. Ejecute el siguiente comando:
2. Unir el nodo de trabajo Windows a un dominio de Active Directory
Depende totalmente de usted elegir el método preferido para unir el nodo de trabajo Windows a un dominio de Active Directory. Puede ser a través de herramientas de automatización o de forma manual. Si utilizó el archivo cluster-spec.yaml en el paso 1 para crear el clúster, el clúster ya tendrá las políticas de IAM necesarias para acceder al nodo de trabajo mediante SSM o manualmente a través de una sesión RDP.
Si su dominio de Active Directory se basa en AWS Directory Service o es local, mediante el conector AD, puede utilizar el comando SSM Run y ejecutar el documento AWS-JoinDirectoryServiceDomain. Asegúrese de que la VPC creada por el clúster de Amazon EKS se comunique con la VPC en la que reside el dominio de Active Directory, a través de VPC peering o Transit Gateway.
Para comprobar que el nodo de trabajo de Windows forma parte del dominio de Active Directory, puede ejecutar un comando de PowerShell desde el propio nodo de trabajo:
El resultado debe ser similar al siguiente:
3. Crear y configurar la cuenta gMSA en el dominio de Active Directory
Si aún no has creado una cuenta gMSA en tu dominio, tendrás que generar una clave raíz del Servicio de Distribución de Claves o Key Distribution Service (KDS). KDS es responsable de crear, rotar y liberar la contraseña gMSA a disposición de los hosts autorizados. Cuando el host de un contenedor necesite usar gMSA para ejecutar un contenedor, se pondrá en contacto con KDS para recuperar la contraseña actual. Si utiliza AWS Managed AD, puede ir directamente al paso 3.3. Los permisos gSMA (group Managed Service Account) están preconfigurados en Microsoft Active Directory administrado por AWS. Como resultado, no necesita generar la clave raíz de KDS para generar las contraseñas gMSA.
3.1 Para comprobar que la clave raíz de KDS ya se ha creado, ejecute el siguiente cmdlet de PowerShell con privilegios de administrador de dominio en un controlador de dominio mediante el módulo AD de PowerShell:
3.2 Si el comando devuelve un identificador de clave, ya está listo. De lo contrario, cree la clave raíz de KDS. Ejecute el siguiente comando:
Si bien el comando sugiere que la clave surtirá efecto inmediatamente, tendrá que esperar 10 horas antes de que la clave raíz de KDS se replique y esté disponible para su uso en todos los controladores de dominio. Si estás interesado en entender mejor las cuentas de gMSA, consulta la documentación oficial de Microsoft.
3.3 Para crear la cuenta de gMSA y permitir que el nodo de trabajo de Windows recupere la contraseña de gMSA, ejecute los siguientes comandos de PowerShell:
Nota: Sustituya YOURDOMAIN_FQDN por su FQDN. Sustituya EKSWORDERNODE01 por el nombre NETBIOS del nodo de trabajo de Windows. No elimines el $ al final, ya que representa una cuenta de equipo en Active Directory.
3.4 Reinicie el nodo de trabajo Windows para que obtenga su nueva pertenencia al grupo.
3.5 Verifique que el host pueda usar la cuenta gMSA. En el nodo de trabajo Windows, instale RSAT-AD-PowerShell. Ejecute los siguientes comandos de PowerShell:
El resultado debe ser similar al siguiente:
4. Instalar gMSA CredentialSpec CRD
Para utilizar autenticación Windows en un clúster de Amazon EKS, debe crear un CustomResourceDefinition (CRD). Los CRD son extensiones de la API de Kubernetes que almacenan una colección de objetos API de un tipo determinado. Extienden la API de Kubernetes o permiten añadir tu propia API al clúster. Se debe configurar un CustomResourceDefinition (CRD) para los recursos gMSA credential spec en el clúster para definir el tipo de recurso personalizado GMSCredentialSpec.
4.1 Cree un archivo llamado gmsa-crd.yaml con el siguiente contenido:
4.2 Cree el CDR en el clúster EKS. Ejecute el siguiente comando:
5. Instalar el Windows gMSA Webhook Admission controller
Según la documentación de firma de certificados de Amazon EKS (https://docs.aws.amazon.com/eks/latest/userguide/cert-signing.html), todos los clústers que ejecuten la versión 1.22 o posterior de Amazon EKS admiten el siguiente certificado firmado beta.eks.amazonaws.com/app-serving for Kubernetes Solicitudes de firma (CSR). Como resultado, sustituiremos el firmante kubernetes.io/kubelet-serving del archivo de instalación del webhook de admisión de gMSA por el firmante beta.eks.amazonaws.com/app-serving compatible con Amazon EKS.
Ejecute el siguiente comando para implementar el gMSA Webhook Admission Controller en el clúster de Amazon EKS y actualizar el firmante:
6. Crear recursos de especificaciones de credenciales gMSA (gMSA credential spec)
Hasta ahora, hemos preparado el clúster de Amazon EKS creando el recurso personalizado que se utilizará con la especificación de credenciales (paso 4) y webhooks para rellenar y validar el recurso en todo el clúster (paso 5). La especificación de credenciales de la gMSA o gSMA credential spec no contiene datos secretos ni confidenciales. Se trata de información que un entorno de ejecución de contenedores puede utilizar para describir la gMSA deseada de un contenedor Windows. Ahora necesitamos crear la especificación de credenciales o credential spec (la misma que se usa en Docker Swarm o Amazon ECS), pero convertida a YAML.
6.1 En el nodo de trabajo Windows de Amazon EKS, ejecute el siguiente comando para instalar el módulo CredentialSpec de Powershell:
6.2 Genere el CredentialSpec ejecutando el siguiente comando:
Nota: Sustituya YOURDOMAIN_FQDN por su FQDN. Sustituya gmsaeks por el nombre de la cuenta gMSA que creó en el paso 3.3.
6.3 Para convertir el CredentialSpec generado en el paso 6.2 de JSON a YAML, cree un script de Powershell con el nombre GenerateCredentialSpecResource.ps1. que contenga el siguiente código.
6.4 Para ejecutar el script, ejecute el siguiente comando:
Nota: Sustituya AccountName por gmsaeks (la cuenta gMSA generada en el paso 3.3). Sustituya ResourceName por el nombre al que desee hacer referencia a CredentialSpec para el clúster de EKS. En este ejemplo: gmsaeks-account.
6.5 Se generó un archivo CredSpec en YAML. Aplíquelo al clúster:
7. Crear un ClusterRole para ser definido para cada gMSA credential sepc
Se debe definir un ClusterRole para cada recurso gMSA credential spec. Esto autoriza el verb del tipo use en un recurso de gMSA específico por parte de un subject que normalmente es una cuenta de servicio.
7.1 Cree un archivo que contenga el siguiente código y guárdelo como gmsa-create-clusterrole.yaml
Nota: Reemplace ResourceNames por el generado en el paso 6.2.
7.2 Para crear el ClusterRole, ejecute el siguiente comando:
8. Asignar el ClusterRole de Kubernetes a una cuenta de servicio específica para la especificación de credenciales gMSA
La cuenta de servicio con la que se configurarán los pods debe estar vinculada al ClusterRole que creamos en el paso 7.1 para autorizar a una cuenta de servicio específica a consumir el recurso gMSA spec. En este blog, utilizaremos la cuenta de servicio estándar, pero puede elegir cualquier otra cuenta que ya tenga en el clúster de EKS.
8.1 Cree un archivo que contenga el código siguiente y guárdelo como gmsa-assign-role.yaml
Nota: Sustituya el roleRef por el nombre del ClusterRole que creó en el paso 7.1.
8.2 Para asignar el ClusterRole a una cuenta de servicio, ejecute el siguiente comando:
9. Configurar del conditional forwarder con CoreDNS
En Amazon EKS, CoreDNS es el servicio DNS estándar que los pods utilizan para la resolución de nombres. Los pods de Windows que requieren autenticación Windows deben poder resolver el FQDN del dominio de Active Directory y, para ello, debe agregar un conditional forwarder en CoreDNS.
9.1 Para modificar el ConfigMap de CoreDNS y añadir la configuración del conditional forwarder, ejecute el siguiente comando:
El resultado debe ser similar al siguiente:
Nota: Sustituya DOMAIN-NAME por su nombre de dominio. Sustituya Custom-DNS-Server-IP por la dirección IP de su servidor DNS personalizado. Guarda eso. (Si usas Windows para ejecutar kubectl, asegúrate de editar el archivo con un editor YAML en lugar de con el Bloc de notas).
El resultado debe ser similar al siguiente:
10. Configurar la especificación de credenciales gMSA en la especificación del pod Windows.
A estas alturas, ya deberías tener todas las configuraciones del clúster Amazon EKS necesarias. Vamos a implementar un pod Windows que utilice gmsCredentialSpecName creando un Deployment en un archivo YAML que contenga el siguiente código:
10.1 Cree un archivo que contenga el siguiente código y guárdelo como Windows-Auth-Pod.yaml
Nota: Sustituya gmsCredentialSpecName por el recurso de credenciales gMSA que creó en el paso 6.2. En este blog, utilizamos gmsaeks-account.
10.2 Implemente el pod de Windows. Ejecute el siguiente comando:
11. Comprobar la autenticación Windows desde el pod Windows
11.1 Ejecute el siguiente comando para ejecutar una sesión de PowerShell dentro del contenedor contenedor:
Nota: Sustituya PODNAME por el nombre de tu pod.
11.2 En la sesión de PowerShell, puede ejecutar el siguiente comando para verificar la identidad gMSA desde dentro del contenedor; ejecutando el siguiente comando y verificando el nombre del cliente. En este blog, gmsaeks es la identidad.
Puede usar el cmdlet nltest para comprobar que la conexión a un DC se ha realizado correctamente; para ello, ejecute el siguiente comando:
Por último, pruébelo accediendo a AD SYSVOL ejecutando el siguiente comando:
Conclusión
Por último, pruébelo accediendo a AD SYSVOL ejecutando el siguiente comando:
Lecturas adicionales:
- Creación de gMSA para contenedores de Windows
- Solución de problemas de gMSA para contenedores de Windows
- Configuración de gMSA para contenedores y pods de Windows (documentación oficial de Kubernetes)
Este artículo fue traducido del Blog da AWS en Inglés.
Acerca de los autores
Marcio Morales es Principal Solutions Architect en Amazon Web Services. Marcio es SME global en contenedores Windows y ayuda a los clientes de AWS a diseñar, crear, proteger y optimizar cargas de trabajo basadas en contenedores Windows en AWS.
Bruno Gabriel es un ingeniero de soporte en la nube del equipo de implementación.
Revisor
Borja Prado es Senior Solutions Architect en AWS, especializado en tecnologías Microsoft. Trabaja ayudando a nuestros clientes en la migración, despliegue y modernización de cargas de trabajo Windows en AWS. Además, está especializado en el diseño y arquitectura de soluciones escalables con .NET y es SME en Sitecore.