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.

---
    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig
    
    metadata:
      name: EKS_CLUSTER_NAME
      region: AWS_REGION
      version: '1.18'
    availabilityZones: 
       - AZ 1
       - AZ 2 
    managedNodeGroups:
      - name: linux-ng
        instanceType: t2.large
        minSize: 1
    
    vpc:
        cidr: 10.10.0.0/16
    
    nodeGroups:
      - name: windows-ng
        instanceType: m5.large
        minSize: 1
        volumeSize: 100
        amiFamily: WindowsServer2019FullContainer
        ssh:
          allow: true
          publicKeyName: NAME_OF_EXISTING_EC2_KEYPAIR
        iam:
          attachPolicyARNs:
            - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
            - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
            - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
            - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM
            - arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
            - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

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:

eksctl create cluster -f cluster-spec.yaml --install-vpc-controllers

1.3 Para administrar el clúster de EKS a través de kubectl, se debe crear un archivo kubeconfig. Ejecute el siguiente comando:

aws eks --region region-code update-kubeconfig --name cluster_name

1.4 Compruebe la configuración. Ejecute el siguiente comando:

kubectl get svc

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:

(Get-WmiObject -Class Win32_ComputerSystem).PartOfDomain

El resultado debe ser similar al siguiente:

Windows Authentication on Amazon EKS Windows pods - Image 1

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:

Get-KdsRootKey

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:

Add-KdsRootKey -EffectiveImmediately

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:

# Create the AD group
New-ADGroup -Name "Amazon EKS Authorized Worker Nodes" -SamAccountName "EKSWorkerNodes" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "gmsaeks" -DnsHostName "gmsaeks.YOURDOMAIN_FQDN" -ServicePrincipalNames "host/gmsaeks", "host/gmsaeks.YOURDOMAIN_FQDN" -PrincipalsAllowedToRetrieveManagedPassword "EKSWorkerNodes"

# Add your Windows Worker Node the AD group
Add-ADGroupMember -Identity "EKSWorkerNodes" -Members "EKSWORDERNODE01$", "EKSWORDERNODE02$", "EKSWORDERNODE03$"

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:

# Install the RSAT AD Feature
Install-WindowsFeature RSAT-AD-PowerShell

# Verify the host can use the gMSA account
Test-ADServiceAccount gmsaeks

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:

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-eks  #This is an arbitrary name but it will be used as a reference
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: gmsaeks   #Username of the GMSA account
      Scope: ad-domain-netbios  #NETBIOS Domain Name
    - Name: gmsaeks   #Username of the GMSA account
      Scope: ad-domain-fqdn #DNS Domain Name
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: ad-domain-fqdn  #DNS Domain Name
    DnsTreeName: ad-domain-fqdn #DNS Domain Name Root
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID
    MachineAccountName: gmsaeks #Username of the GMSA account
    NetBiosName: ad-domain-netbios  #NETBIOS Domain Name
    Sid: S-1-5-21-857038504-468933455-1338018723-94603 #SID of GMSA

4.2 Cree el CDR en el clúster EKS. Ejecute el siguiente comando:

kubectl apply -f gmsa-crd.yaml

5. Instalar el Windows gMSA Webhook Admission controller

Según la documentación de firma de certificados de Amazon EKS (https://docs.thinkwithwp.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:

git clone https://github.com/kubernetes-sigs/windows-gmsa.git
cd windows-gmsa/admission-webhook/deploy
sed -i.back "s/signerName: kubernetes.io\/kubelet-serving/signerName: beta.eks.amazonaws.com\/app-serving/g" create-signed-cert.sh
K8S_GMSA_DEPLOY_DOWNLOAD_REV='v0.4.0' ./deploy-gmsa-webhook.sh --file ./gmsa-manifests --image sigwindowstools/k8s-gmsa-webhook:v0.4.0 --overwrite

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:

Install-Module CredentialSpec

6.2 Genere el CredentialSpec ejecutando el siguiente comando:

New-CredentialSpec -Name gmsaeks -AccountName gmsaeks -Domain YOURDOMAIN_FQDN

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.

<#
.Synopsis
 Renders a GMSA kubernetes resource manifest.
#>
Param(
 [Parameter(Position = 0, Mandatory = $true)] [String] $AccountName,
 [Parameter(Position = 1, Mandatory = $true)] [String] $ResourceName,
 [Parameter(Position = 2, Mandatory = $false)] [String] $ManifestFile,
 [Parameter(Mandatory=$false)] $Domain,
 [Parameter(Mandatory=$false)] [string[]] $AdditionalAccounts = @()
)
# Logging for troubleshooting
Start-Transcript -Path "C:\gmsa\CredSpec.txt"
# exit on error
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
$PSDefaultParameterValues['*:ErrorAction'] = 'Stop'
# generate the name of the output file if not specified
if (-not $ManifestFile -or $ManifestFile.Length -eq 0) {
 $ManifestFile = "gmsa-cred-spec-$ResourceName.yml"
}
# check the out file doesn't exist
if ([System.IO.File]::Exists($ManifestFile)) {
 throw "Output file $ManifestFile already exists, refusing to overwrite it"
}
# install the dependencies we need
if (-not (Get-WindowsFeature rsat-ad-powershell).Installed) {
 Add-WindowsFeature rsat-ad-powershell
}
if (-not (Get-Command ConvertTo-Yaml -errorAction SilentlyContinue)) {
 Install-Module powershell-yaml -Force
}
# download the canonical helper script
Invoke-WebRequest "https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1" -UseBasicParsing -OutFile $env:TEMP\cred.psm1
Import-Module $env:temp\cred.psm1
# generate a unique docker cred spec name
$dockerCredSpecName = "tmp-k8s-cred-spec" + -join ((48..57) + (97..122) | Get-Random -Count 64 | ForEach-Object {[char]$_})
# have the upstream function perform its magic
if (-not $Domain) {
 $Domain = Get-ADDomain
}
New-CredentialSpec -Name $dockerCredSpecName -AccountName $AccountName -Domain $Domain.DnsRoot -AdditionalAccounts $AdditionalAccounts
# parse the JSON file thus generated
$dockerCredSpecPath = (Get-CredentialSpec | Where-Object {$_.Name -like "$dockerCredSpecName*"}).Path
$credSpecContents = Get-Content $dockerCredSpecPath | ConvertFrom-Json
# and clean it up
Remove-Item $dockerCredSpecPath
# generate the k8s resource
$resource = [ordered]@{
 "apiVersion" = "windows.k8s.io/v1alpha1";
 "kind" = 'GMSACredentialSpec';
 "metadata" = @{
 "name" = $ResourceName
 };
 "credspec" = $credSpecContents
}
ConvertTo-Yaml $resource | Set-Content $ManifestFile
Write-Output "K8S manifest rendered at $ManifestFile"

6.4 Para ejecutar el script, ejecute el siguiente comando:

.\GenerateCredentialSpecResource.ps1

Windows Authentication on Amazon EKS Windows pods - Image 3

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:

kubectl apply -f gmsa-cred-spec-gmsaeks-account.yml

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

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eksgmsa-role 
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsaeks-account"]

Nota: Reemplace ResourceNames por el generado en el paso 6.2.

7.2 Para crear el ClusterRole, ejecute el siguiente comando:

kubectl apply -f gmsa-create-clusterrole.yaml

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

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmsa-assign-role
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: eksgmsa-role
  apiGroup: rbac.authorization.k8s.io

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:

kubectl apply -f gmsa-assign-role.yaml

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:

kubectl -n kube-system edit configmap coredns

El resultado debe ser similar al siguiente:

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
  labels:
    eks.amazonaws.com/component: coredns
    k8s-app: kube-dns
  name: coredns
  namespace: kube-system
data:
  Corefile: | .:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } DOMAIN-NAME:53 { errors cache 30 forward . custom-dns-server-IP1 custom-dns-server-IP2 reload }

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:

Windows Authentication on Amazon EKS Windows pods - IMage 4

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

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: amazon-eks-gmsa-test
  name: amazon-eks-gmsa-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: amazon-eks-gmsa-test
  template:
    metadata:
      labels:
        run: amazon-eks-gmsa-test
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsaeks-account
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

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:

kubectl apply -f Windows-Auth-Pod.yaml

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:

kubectl exec -it PODNAME -- powershell.exe

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.

klist get krbtgt

Puede usar el cmdlet nltest para comprobar que la conexión a un DC se ha realizado correctamente; para ello, ejecute el siguiente comando:

nltest /sc_verify:YOURDOMAINQFN

Windows Authentication on Amazon EKS Windows pods - Image 6

Por último, pruébelo accediendo a AD SYSVOL ejecutando el siguiente comando:

dir \\YOURDOMAINFQDN\sysvol

Windows Authentication on Amazon EKS Windows pods - Image 7

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.

Blog de Amazon Web Services (AWS)

Autenticación Windows con Windows Pods en Amazon EKS

¿Cómo vamos a lograrlo?

En este blog, realizaremos las siguientes tareas:

1. Crear un clúster de EKS con nodos de trabajo de Windows autogestionados

2. Unir el nodo de trabajo Windows a un dominio de Active Directory

3. Crear y configurar la cuenta gMSA en el dominio de Active Directory

4. Instalar gMSA CredentialSpec CRD

5. Instalar el Windows gMSA Webhook Admission controller

6. Crear recursos de especificaciones de credenciales gMSA (gMSA credential spec)

7. Crear un ClusterRole para ser definido para cada gMSA credential sepc

8. Asignar el ClusterRole de Kubernetes a una cuenta de servicio específica para la especificación de credenciales gMSA

9. Configurar del conditional forwarder con CoreDNS

10. Configurar la especificación de credenciales gMSA en la especificación del pod Windows.

11. Comprobar la autenticación Windows desde el pod Windows

Conclusión

Acerca de los autores

Revisor