Desplegar aplicaciones ASP.NET con autenticación de Windows en contenedores de Windows de GKE

Arquitectura

Las aplicaciones basadas en Windows que se ejecutan en un Windows Server unido a un dominio suelen usar identidades de Microsoft Active Directory (AD) para autenticar a usuarios y aplicaciones. Estos son algunos de los usos más habituales:

• Crear aplicaciones web ASP.NET que usen la autenticación integrada de Windows para autenticar a los usuarios de Active Directory cuando intenten iniciar sesión en la aplicación web.
• Crear aplicaciones que usen la cuenta de ordenador de Active Directory del servidor para acceder a recursos a través de la red, como un recurso compartido SMB remoto o una instancia remota de Microsoft SQL Server.

Los contenedores de Windows no se pueden unir a un dominio y, por lo tanto, no tienen cuentas de ordenador en Active Directory. Por este motivo, las aplicaciones web ASP.NET que se ejecutan en contenedores de Windows no pueden autenticar a los usuarios de Active Directory mediante la autenticación integrada de Windows y, por lo tanto, no pueden acceder a los recursos protegidos de la red. Para obtener más información sobre cómo accede ASP.NET a los recursos protegidos, consulta Identidades del grupo de aplicaciones en la documentación de Microsoft.

En lugar de usar una cuenta de ordenador, los contenedores de Windows pueden usar una identidad de cuenta de servicio gestionada por grupos (gMSA) de Active Directory para acceder a Active Directory y a otros recursos protegidos de la red, como recursos compartidos de archivos e instancias de SQL Server. Para obtener más información, consulta el artículo Resumen de las cuentas de servicio gestionadas por grupos de la documentación de Microsoft.

En el siguiente diagrama de arquitectura se muestran los recursos que se usan en este tutorial:

En el diagrama se muestran los siguientes elementos:

• Máquina virtual de desarrollo. En este tutorial, crearás una VM de Windows Server que usarás para crear la imagen de contenedor de la aplicación web ASP.NET y para crear la gMSA.
• Clúster y nodos de GKE. El clúster de GKE de este tutorial tiene un grupo de nodos de Linux y un grupo de nodos de Windows Server que se usan de las siguientes formas:
  • Los nodos de Linux ejecutan componentes del sistema que solo se ejecutan en los sistemas operativos Linux, como el servidor de métricas de GKE.
  • Los nodos de Windows Server se usan para alojar contenedores de Windows Server y están unidos a un dominio de Active Directory.
• Infraestructura de Active Directory. Para que los nodos de Windows de GKE se unan al dominio, primero debes seguir el tutorial Configurar Active Directory para que las máquinas virtuales se unan automáticamente a un dominio. En ese tutorial, se crea un servicio de Cloud Run que se encarga de registrar nuevos ordenadores (instancias) en Active Directory y de proporcionar a cada nueva instancia una contraseña temporal que la instancia utiliza para completar el proceso de unión al dominio. Cada nueva instancia del grupo de nodos de Windows Server llama al servicio de Cloud Run para unirse al dominio de Active Directory.
• Balanceador de carga de red. Cuando un usuario local abre su navegador y va a la aplicación web ASP.NET, el tráfico pasa por un equilibrador de carga de red. GKE crea el balanceador de carga cuando creas un servicio LoadBalancer de GKE para tu aplicación web. El usuario también se autentica en la aplicación web enviando sus credenciales de Active Directory a la aplicación web.

Crear la infraestructura

Una vez que hayas completado el tutorial relacionado, crea los componentes de infraestructura del tutorial actual, que incluyen lo siguiente:

• Una VM de Windows Server que tenga una imagen de contenedor de aplicación web ASP.NET.
• Un clúster de GKE que tiene un grupo de nodos de Windows Server.
• Reglas de cortafuegos que dan acceso a los pods de GKE a Active Directory.
• Un webhook en el clúster de GKE que gestiona la configuración y la población de recursos de gMSA en las implementaciones.

Crear una VM de desarrollo

La imagen de contenedor de Windows Server que crees debe coincidir con la versión de Windows Server de la VM en la que crees la imagen de contenedor. Esta versión también debe coincidir con la versión de Windows Server de tus nodos de Windows Server de GKE. Si creas una imagen de contenedor o ejecutas un contenedor en una versión diferente de Windows Server, se produce un error. Para obtener más información sobre los requisitos de compatibilidad de los contenedores de Windows, consulta Matching container host version with container image versions (Emparejar la versión del host del contenedor con las versiones de la imagen del contenedor).

En este tutorial se usa la versión 2022 del canal de mantenimiento a largo plazo (LTSC) de Windows Server para la VM, los nodos de Windows Server en GKE y la imagen de contenedor. Para obtener más información, consulta la asignación de versiones entre las versiones de Windows Server y las de GKE.

1. In the Trusted Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Trusted Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Si PowerShell está abierto, ciérralo escribiendo exit.

3. Define las variables de entorno para el nombre de la red y la subred, así como para la URL del servicio de Active Directory:

   export NETWORK_NAME=NETWORK-NAME
   export SUBNETWORK_NAME=SUBNETWORK-NAME
   export AD_JOIN_SERVICE_URL=AD-JOIN-SERVICE-URL
   

   Haz los cambios siguientes:

   • NETWORK-NAME: la red de VPC en la que se van a implementar las VMs.
   • SUBNETWORK-NAME: la subred en la que se van a desplegar las VMs.
   • AD-JOIN-SERVICE-URL: la URL del servicio de Cloud Run que has desplegado en la sección Antes de empezar.

4. Define el Trusted Cloud ID de proyecto y la región del entorno actual:

   gcloud config set project PROJECT-ID
   gcloud config set compute/zone ZONE-NAME
   

   Haz los cambios siguientes:

   • PROJECT-ID: tu ID de proyecto Trusted Cloud .
   • ZONE-NAME: la zona en la que se desplegarán todas las VMs. Para reducir la latencia, le recomendamos que seleccione una zona de la misma región en la que haya implementado el servicio de Cloud Run de unión al dominio de Active Directory.

5. Crea una cuenta de servicio para la VM de desarrollo:

   export SERVICE_ACCOUNT_NAME=dev-vm
   export SERVICE_ACCOUNT_EMAIL=$SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.s3ns.iam.gserviceaccount.com
   
   gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \
       --display-name="Development VM Service Account"
   

6. Concede acceso a la cuenta de servicio a Artifact Registry:

   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
       --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
       --role="roles/artifactregistry.writer"
   

7. Concede a la cuenta de servicio acceso a GKE:

   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
       --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
       --role="roles/container.admin"
   

   A la cuenta de servicio se le asigna el rol container.admin porque este rol tiene permisos para crear clústeres de GKE en el proyecto y para gestionar recursos en clústeres, incluidos los recursos de control de acceso basado en roles (RBAC). Los recursos de RBAC son necesarios para controlar qué pod tiene permiso para usar un gMSA.

8. Crea una VM de Windows Server 2022:

   gcloud compute instances create gmsa-dev-vm \
       --image-project windows-cloud \
       --image-family windows-2022-core \
       --machine-type n1-standard-2 \
       --boot-disk-type=pd-ssd \
       --boot-disk-size=100GB \
       --network $NETWORK_NAME \
       --subnet $SUBNETWORK_NAME \
       --service-account=$SERVICE_ACCOUNT_EMAIL \
       --scopes https://www.googleapis.com/auth/cloud-platform \
       --metadata sysprep-specialize-script-ps1="iex((New-Object System.Net.WebClient).DownloadString('$AD_JOIN_SERVICE_URL')); Add-WindowsFeature RSAT-AD-PowerShell"
   

   Si tiene previsto desplegar sus aplicaciones en contenedores de Windows Server 2019, cambie el valor del parámetro --image-family a windows-2019-core-for-containers.

   El permiso https://www.googleapis.com/auth/cloud-platform permite que la instancia acceda a todas las APIs Trusted Cloud , en función de los roles de IAM que se definan para la cuenta de servicio de la instancia.

   La VM se crea con una dirección IP externa para que pueda comunicarse con Internet. La VM debe tener acceso a Internet para poder descargar varias utilidades, como git y kubectl, así como para descargar la aplicación web ASP.NET de GitHub.

   Durante la fase sysprep, la nueva instancia se une al dominio de Active Directory para que puedas acceder a ella de forma remota con tu cuenta de dominio. La secuencia de comandos del comando sysprep también instala el módulo de PowerShell para Active Directory.

Crear un repositorio de Docker de Artifact Registry

1. En Cloud Shell, define la ubicación predeterminada de los nuevos repositorios de Artifact Registry:

   gcloud config set artifacts/location LOCATION
   

   Sustituye LOCATION por la región en la que quieras crear el repositorio de Artifact Registry. Para reducir la latencia, te recomendamos que selecciones la misma región en la que has implementado la VM de desarrollo.

2. Crea el repositorio de Docker de Artifact Registry:

   gcloud artifacts repositories create windows-container-images \
       --repository-format=docker
   

Crear un clúster de GKE

1. En Cloud Shell, define una variable de entorno para el nombre del clúster de GKE:

   export GKE_CLUSTER_NAME=cluster-1
   

2. Crea el clúster de GKE:

   gcloud container clusters create $GKE_CLUSTER_NAME \
       --release-channel rapid \
       --network $NETWORK_NAME \
       --subnetwork $SUBNETWORK_NAME \
       --enable-ip-alias
   

   Si se asigna el parámetro --release-channel a rapid, se implementa el clúster de GKE con la versión más reciente de Kubernetes. El parámetro --enable-ip-alias activa la IP de alias. Se necesita una IP de alias para los nodos de Windows Server.

Crear un grupo de nodos de Windows Server en GKE

Cuando creas un clúster de GKE a través de la CLI, el clúster se crea con un grupo de nodos de Linux. Para usar Windows Server en GKE, debes crear un grupo de nodos de Windows Server.

Los clústeres de GKE deben tener al menos un nodo de Linux para ejecutar los contenedores internos (del sistema) del clúster. No se puede crear un clúster de GKE solo con nodos de Windows Server.

1. En Cloud Shell, define una variable de entorno para el nombre del grupo de nodos del servidor Windows:

   export NODE_POOL_NAME=windows-server-pool
   

2. Crea un grupo de nodos de Windows Server de GKE:

   gcloud container node-pools create $NODE_POOL_NAME \
       --cluster $GKE_CLUSTER_NAME \
       --machine-type n1-standard-2 \
       --image-type WINDOWS_LTSC_CONTAINERD \
       --windows-os-version=ltsc2022 \
       --num-nodes 2 \
       --no-enable-autoupgrade \
       --metadata sysprep-specialize-script-ps1="iex((New-Object System.Net.WebClient).DownloadString('$AD_JOIN_SERVICE_URL'))"
   

   Si tienes previsto implementar tus aplicaciones en contenedores en contenedores de Windows Server 2019, cambia el parámetro --windows-os-version por ltsc2019.

   La clave de metadatos sysprep-specialize-script-ps1 es una clave integrada que apunta a una secuencia de comandos de PowerShell que se ejecuta durante el paso GCESysprep antes de que la instancia se inicie por primera vez.

   El cmdlet iex descarga la secuencia de comandos de PowerShell del servicio de unión al dominio de Active Directory que has desplegado en Cloud Run. A continuación, ejecuta la secuencia de comandos que une la nueva instancia al dominio de Active Directory.

   El parámetro --no-enable-autoupgrade inhabilita la actualización automática de nodos en todos los nodos del grupo. Esto se debe a que, al actualizar la imagen de Windows de un nodo, puede producirse una incompatibilidad entre la versión de Windows Server del nodo y la versión de Windows Server del pod. Para obtener más información, consulta Actualizar grupos de nodos de Windows Server.

   Después de crear cada nodo, la secuencia de comandos de domain-join PowerShell une el nodo al dominio.

3. Espera varios minutos hasta que se cree el grupo de nodos y, a continuación, ejecuta el siguiente comando para verificar que todos los nodos se han unido al dominio:

   kubectl get node \
   -l cloud.google.com/gke-nodepool=$NODE_POOL_NAME \
   -o custom-columns=":metadata.name" --no-headers \
       | xargs -I{} gcloud compute instances get-serial-port-output {} --port 1 \
       | grep "sysprep-specialize-script-ps1:.*success" --ignore-case
   

   Si los nodos se han unido al dominio, el resultado es el siguiente:

   timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Successfully registered computer account.
   timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Computer successfully joined to domain
   
   Specify --start=152874 in the next get-serial-port-output invocation to get only the new output starting from here.
   

   Si quieres ver el resultado completo de la secuencia de comandos, elimina .*success del comando grep.

Conceder acceso a Active Directory a los pods de GKE

Debes crear una regla de cortafuegos que permita que los pods del clúster de GKE accedan a tus controladores de dominio mediante los siguientes protocolos:

• Kerberos (UDP/88, TCP/88)
• NTP (UDP/123)
• RPC (TCP/135, TCP/49152-65535)
• LDAP (UDP/389, TCP/389)
• SMB (UDP/445, TCP/445)
• GC de LDAP (TCP/3268)
• Servicios web de Active Directory (TCP/9389)

Puedes aplicar la regla en función de una cuenta de servicio que hayas asignado a tus controladores de dominio o puedes aplicarla mediante una etiqueta de red, como se hace en este tutorial. Para obtener más información sobre los puertos relacionados con Active Directory, consulta la documentación sobre los requisitos de puertos y protocolos de Active Directory y sobre cómo usar Active Directory en firewalls.

Si utilizas el servicio gestionado para Microsoft Active Directory (Microsoft AD gestionado), puedes saltarte este procedimiento.

1. En Cloud Shell, obtén el intervalo de direcciones IP de los pods del clúster de GKE:

   CLUSTER_IP_RANGE=`gcloud container clusters describe $GKE_CLUSTER_NAME --format="value(clusterIpv4Cidr)"`
   

2. Crea una regla de cortafuegos para dar acceso a los pods de GKE a Active Directory:

   gcloud compute firewall-rules create allow-gke-pods-to-ad \
       --network $NETWORK_NAME \
       --allow udp:88,tcp:88,udp:123,tcp:135,tcp:49152-65535,udp:389,tcp:389,udp:445,tcp:445,tcp:3268,tcp:9389 \
       --source-ranges=$CLUSTER_IP_RANGE \
       --target-tags DC-TAG
   

   Sustituye DC-TAG por la etiqueta de red asignada a las VMs de tus controladores de dominio.

Configurar GKE para que admita el uso de gMSAs

Para usar una gMSA en nodos de Windows Server, debes crear el objeto gMSA en Active Directory, crear un recurso gMSA coincidente en GKE y habilitar los pods recién creados para que obtengan sus credenciales de gMSA.

1. En Cloud Shell, descarga y ejecuta la secuencia de comandos del webhook de gMSA:

   export K8S_GMSA_DEPLOY_DOWNLOAD_REV=b685a27adc40511bb5756dfb3ada2e8578ee72e1
   curl https://raw.githubusercontent.com/kubernetes-sigs/windows-gmsa/$K8S_GMSA_DEPLOY_DOWNLOAD_REV/admission-webhook/deploy/deploy-gmsa-webhook.sh -o deploy-gmsa-webhook.sh && chmod +x deploy-gmsa-webhook.sh
   
   ./deploy-gmsa-webhook.sh --file ./gmsa-webhook.yml --namespace gmsa-webhook --overwrite
   rm -drf gmsa-webhook-certs
   

   La secuencia de comandos añade el manifiesto de la definición de recurso personalizado (CRD) de gMSA a tu clúster de GKE e implementa un webhook que proporciona las especificaciones de gMSA a los pods. Ahora puede almacenar especificaciones de gMSA en su clúster y configurar gMSAs para pods y contenedores.

   Para obtener más información sobre Kubernetes y gMSAs, consulta Configurar gMSA para pods y contenedores de Windows.

Tu clúster de GKE ya está listo para ejecutar aplicaciones de Windows que requieran el uso de una gMSA. Por ejemplo, puedes ejecutar una aplicación web ASP.NET en tus nodos de Windows Server. Puedes configurar la aplicación para que los usuarios inicien sesión con la autenticación de Windows o para que la aplicación use la cuenta gMSA del pod para acceder a un recurso compartido de red remoto o a una base de datos de SQL Server.

Integración con Active Directory

A continuación, crea una gMSA para tu aplicación web ASP.NET en Active Directory, configura cómo y quién puede usarla y, después, añade su configuración a GKE.

Inicia sesión y abre PowerShell

1. Conéctate a la VM gmsa-dev-vm.

2. Inicia sesión en Windows con una cuenta de Active Directory que tenga permiso para crear una gMSA.

   Tu cuenta debe ser miembro del grupo Domain Admins o poder crear objetos msDS-GroupManagedServiceAccount. Para obtener más información, consulta Provisioning group Managed Service Accounts (Provisionar cuentas de servicio gestionadas por grupos).

   Si usas Managed Microsoft AD, tu cuenta debe ser miembro del grupo Cloud Service Managed Service Account Administrators. Para obtener más información, consulta el artículo sobre cómo delegar la administración de cuentas de servicio gestionadas.

3. Escribe 15 para salir del menú y volver a la línea de comandos (PowerShell).

Instalar un entorno de ejecución de contenedores

Windows Server 2022 requiere un entorno de ejecución de contenedores, como Docker Community Edition (CE), para crear y ejecutar contenedores de Windows. Para obtener más información sobre cómo instalar un tiempo de ejecución de contenedor en Windows Server, consulta el artículo Empezar: preparar Windows para contenedores de la documentación de Microsoft.

Si has creado la VM de desarrollo con la imagen windows-2019-core-for-containers, puedes saltarte el siguiente procedimiento, ya que la imagen ya tiene Docker instalado.

1. Instala Docker Community Edition (CE):

   Invoke-WebRequest -UseBasicParsing -o install-docker-ce.ps1 `
      "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1"
   .\install-docker-ce.ps1
   

   Si la conexión a escritorio remoto se cierra durante el proceso de instalación, vuelve a conectarte a la VM.

2. Espera a que se complete el proceso de instalación y, a continuación, escribe exit para cerrar la nueva ventana de PowerShell.

3. Escribe 15 para salir del menú y volver a la línea de comandos (PowerShell).

Crear una clave raíz de KDS

Antes de crear una gMSA, debes asegurarte de que tu controlador de dominio de Active Directory tenga una clave raíz de servicios de distribución de claves (KDS). Active Directory usa la clave raíz de KDS para generar contraseñas de gMSAs.

Si usas Managed Microsoft AD, puedes saltarte el siguiente procedimiento, ya que Managed Microsoft AD crea la clave raíz de KDS cuando creas el dominio.

1. En gmsa-dev-vm, comprueba si Active Directory ya tiene la clave raíz de KDS:

   Get-KdsRootKey
   

   Este comando muestra el ID de clave, si existe.

2. Si no recibes un ID de clave en la respuesta, crea la clave:

   Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
   

Crear la gMSA

Cuando creas una gMSA, debes proporcionar los nombres de los ordenadores que tienen acceso a ella. Como práctica recomendada de seguridad, debe conceder permiso a la gMSA solo a las instancias en las que se ejecute su aplicación. Cuando creas un grupo de nodos de Windows Server unido a un dominio, se crea un grupo de Active Directory para los ordenadores del grupo de nodos. El nombre del grupo coincide con el nombre del grupo de instancias gestionado (MIG) que GKE crea para el pool de nodos.

1. En PowerShell, define las variables del ID de proyecto, el nombre del clúster, el nombre del grupo de nodos de Windows, el nombre de la gMSA y el nombre del dominio de AD: Trusted Cloud

   $ProjectId = "PROJECT-ID"
   $GkeClusterName = "cluster-1"
   $PermittedNodePool = "windows-server-pool"
   $GmsaName = "WebApp-01"
   $AdDomain = (Get-ADDomain).DNSRoot
   

   Sustituye PROJECT-ID por el ID de tu proyecto. Trusted Cloud

2. Define la configuración del clúster para la herramienta gcloud:

   gcloud config set project $ProjectId
   gcloud config set compute/zone "ZONE-NAME"
   

   Sustituye ZONE-NAME por la zona en la que has desplegado el clúster de GKE.

3. Recupera el nombre de dominio del grupo de Active Directory que se ha creado para el grupo de nodos:

   $InstanceGroupUri = gcloud container node-pools describe $PermittedNodePool `
       --cluster $GkeClusterName `
       --format="value(instanceGroupUrls)"
   $InstanceGroupName=([System.Uri]$instanceGroupUri).Segments[-1]
   $GroupDN=(Get-ADGroup -Filter "name -eq '$InstanceGroupName'")
   
   Write-Host $GroupDN.DistinguishedName
   

4. Crea la gMSA:

   New-ADServiceAccount -Name $GmsaName `
   -DNSHostName "$GmsaName.$AdDomain" `
   -PrincipalsAllowedToRetrieveManagedPassword $GroupDN
   

5. Verifica que se haya creado la gMSA:

   Get-ADServiceAccount -Identity $GmsaName
   

   Si se ha creado la gMSA, el resultado será similar al siguiente:

   DistinguishedName : CN=WebApp01,CN=Managed Service Accounts,DC=corp,DC=example,DC=com
   Enabled           : True
   Name              : WebApp01
   ObjectClass       : msDS-GroupManagedServiceAccount
   ObjectGUID        : 5afcff45-cf15-467d-aaeb-d65e53288253
   SamAccountName    : WebApp01$
   SID               : S-1-5-21-780151012-601164977-3226406772-2103
   UserPrincipalName :
   

Añadir la gMSA a GKE

Para usar una gMSA en un clúster de Kubernetes, debes crear un recurso gMSA en Kubernetes y configurar qué espacios de nombres y cuentas pueden usarla.

1. En gmsa-dev-vm, en PowerShell, instala la herramienta git:

   Install-Script -Name Install-Git -Force
   Install-Git.ps1
   $env:Path += ";c:\program files\git\bin"
   

2. Instala la herramienta kubectl:

   $version = (Invoke-WebRequest -UseBasicParsing -Uri "https://dl.k8s.io/release/stable.txt").Content
   $uri = "https://dl.k8s.io/release/$version/bin/windows/amd64/kubectl.exe"
   New-Item -Type Directory $env:ProgramFiles\kubectl
   Start-BitsTransfer -Source $uri -Destination $env:ProgramFiles\kubectl\
   $env:Path += ";$env:ProgramFiles\kubectl"
   

3. Instala el archivo binario gke-gcloud-auth-plugin:

   gcloud components install gke-gcloud-auth-plugin
   

   Espera varios minutos a que finalice el proceso de instalación.

4. Inicializa la herramienta kubectl con las credenciales de tu clúster de GKE:

   gcloud container clusters get-credentials $GkeClusterName
   

5. Crea el archivo de especificación de credenciales de gMSA:

   Install-Module CredentialSpec -Force
   $GmsaName = $GmsaName.ToLower()
   $CredSpecFile = Join-Path $env:TEMP "$GmsaName-credspec.json"
   New-CredentialSpec -AccountName $GmsaName -Path $CredSpecFile
   
   $CredentialsSpec=@{
   "apiVersion" = "windows.k8s.io/v1";
   "kind" = "GMSACredentialSpec";
   "metadata" = @{"name" = $GmsaName}
   "credspec" = (Get-Content $CredSpecFile | ConvertFrom-Json)
   }
   
   $CredentialsSpec | ConvertTo-Json -Depth 5 | Set-Content $CredSpecFile
   

   El nombre del recurso GMSACredentialSpec en Kubernetes debe usar caracteres en minúsculas.

   La secuencia de comandos cambia las mayúsculas y minúsculas de la variable $GmsaName para cumplir esta restricción.

   La secuencia de comandos muestra un mensaje de advertencia que indica que no se ha podido probar la cuenta de servicio gestionada, lo cual es normal. Tu VM de desarrollo no es miembro del grupo asignado a la gMSA y, por lo tanto, no puedes probar la gMSA desde la VM. El mensaje de advertencia no impide que el comando genere la especificación de credenciales de gMSA.

6. Añade la especificación de las credenciales de gMSA al clúster de GKE:

   kubectl apply -f $CredSpecFile
   

7. Clona el repositorio de GitHub:

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd kubernetes-engine-samples/windows/aspnet-gmsa/
   

8. Añade los objetos RBAC de gMSA a tu clúster:

   kubectl apply -f gmsa-rbac-webapp-01.yaml
   

   El gmsa-rbac-webapp-01.yaml crea un objeto RBAC ClusterRole para la gMSA y, a continuación, vincula el nuevo rol de clúster a la cuenta de servicio predeterminada en el espacio de nombres default. Si vas a desplegar tu aplicación en un espacio de nombres diferente, edita el archivo gmsa-rbac-webapp-01.yaml y cambia el espacio de nombres de la vinculación de roles y de la cuenta de servicio.

Desplegar y usar la aplicación web

A continuación, compila la aplicación web y la imagen de contenedor, despliega la nueva imagen de contenedor en tu clúster de GKE y abre la aplicación web en el navegador para verificar que puede usar la gMSA.

Compilar y desplegar la aplicación web ASP.NET

1. En gmsa-dev-vm, en PowerShell, define las variables de la ubicación del registro, el nombre del registro y la etiqueta de la imagen:

   $RegistryLocation = "LOCATION-docker.pkg.dev"
   $ProjectsRegistry = "$RegistryLocation/$ProjectId"
   $ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
   

   Sustituye LOCATION por la ubicación en la que has creado el repositorio de Artifact Registry.

2. Crea la imagen del contenedor:

   docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
   

   Para crear imágenes de contenedor para Windows Server 2019, asigna el valor Dockerfile-WINDOWS_LTSC2019 al parámetro -f.

3. Envía la imagen de contenedor a Artifact Registry:

   gcloud auth configure-docker $RegistryLocation --quiet
   docker push $ImageTag
   

4. Descarga el archivo YAML de la aplicación y actualízalo con tu configuración de gMSA:

   $ApplicationYaml = Join-Path $env:TEMP "gmsa-test-webapp-01.yaml"
   
   (Get-Content gmsa-test-webapp-01.yaml.template) `
   -Replace '\${image_path}',$ImageTag | `
   Set-Content $ApplicationYaml
   

   Si creas nodos de Windows Server 2019 en GKE, edita el archivo YAML de la aplicación y cambia el valor de cloud.google.com/gke-windows-os-version de 2022 a 2019.

5. Despliega la aplicación web en tu clúster de GKE:

   kubectl apply -f $ApplicationYaml
   

Verificar que la aplicación web ASP.NET se está ejecutando

La aplicación web se expone a Internet mediante un servicio LoadBalancer. Antes de poder acceder a la aplicación web, debes esperar a que se implementen el pod y el servicio. El despliegue del pod puede tardar varios minutos porque las imágenes de contenedor de Windows Server Core son grandes (la imagen de la aplicación web ocupa más de 7 GB) y el nodo tarda un tiempo en descargar la imagen y crear el contenedor.

1. Comprueba el estado del Pod:

   kubectl get pods --selector=app=gmsa-test-webapp-01
   

   Repite el comando hasta que el resultado muestre que el estado del pod es Running:

   NAME                                   READY     STATUS    RESTARTS   AGE
   gmsa-test-webapp-01-76c6d64975-zrtgq   1/1       Running   0          28s
   

   Si el estado del pod sigue siendo Pending y no cambia a ContainerCreating o Running, comprueba la imagen de origen de tu nodo de Windows para asegurarte de que sea Windows Server 2022. También puedes consultar la tabla de asignación de versiones para ver cómo se asignan las versiones de GKE a las de Windows Server. Si las versiones no coinciden, duplica el archivo Dockerfile-WINDOWS_LTSC2022, define la imagen de contenedor base en el nuevo archivo para que coincida con la versión de Windows Server de tus nodos y, a continuación, repite los pasos para compilar e implementar la aplicación web ASP.NET.

2. Comprueba el estado del servicio:

   kubectl get service --selector=app=gmsa-test-webapp-01
   

   Repite el comando hasta que el resultado muestre que el servicio tiene una dirección IP externa:

   NAME                   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
   gmsa-test-webapp-01    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s
   

3. Anota el valor de external-ip en el resultado. Lo necesitarás más adelante.

Realizar pruebas preliminares en la aplicación web ASP.NET

El pod ahora está en ejecución y se puede acceder a él desde Internet a través de un balanceador de carga de red. A continuación, ejecuta pruebas preliminares para verificar que el contenedor se ha implementado correctamente y que tiene permisos para usar la cuenta de servicio administrada por grupo (gMSA).

1. En un navegador, ve a http://EXTERNAL-IP para ver la aplicación web de prueba de gMSA.

   Sustituye EXTERNAL-IP por la dirección IP que has obtenido en el procedimiento anterior.

2. Desplázate hasta la sección Comprobaciones preparatorias y, a continuación, haz clic en el botón Ejecutar comprobaciones preparatorias para verificar que se han superado todas las pruebas.

   Si las pruebas se superan, el resultado es el siguiente:

   [PASS]  Active Directory RSAT PowerShell Module Installed
   
   [PASS]  IIS Document Root found
           C:\inetpub\wwwroot\
   
   [PASS]  PowerShell Scripts Folder found
           C:\inetpub\wwwroot\Powershell\
   
   [PASS]  Container Diagnostic Script found
           C:\inetpub\wwwroot\Powershell\\containerDiag.ps1
   
   [PASS]  Domain Diagnostic Script found
           C:\inetpub\wwwroot\Powershell\\domainDiag.ps1
   
   [RES]   Result: PASS   All checks passed! Please proceed to run the different tests.
   

3. Desplázate hasta la sección Información del contenedor y haz clic en el botón Ejecutar secuencia de comandos. Comprueba que se muestre información sobre el contenedor y el nodo, y que no se muestre ningún error.

Usar la gMSA en contenedores de Windows

Ahora puedes verificar que la configuración de la cuenta de servicio administrada por grupo funciona correctamente ejecutando varias pruebas en la aplicación web. Cada una de las pruebas usa la gMSA para un propósito diferente. Si todas las pruebas se realizan correctamente, significa que has configurado la gMSA correctamente.

Validar la configuración del contenedor de gMSA

• Desplázate hasta la sección Conectividad de dominio, escribe el nombre de tu cuenta de servicio administrada de grupo (WebApp-01) en el cuadro Nombre de cuenta y, a continuación, haz clic en Ejecutar secuencia de comandos. Espera unos segundos a que finalicen las pruebas.

  El resultado debería ser similar al siguiente:

  *****   C O N T A I N E R   D I A G N O S T I C S   *****
  
  [INFO]  Starting script execution at 01-05-2021-13:53:11
  
  [INFO]  Using gMSA: WebApp-01
  
  [PASS]  gMSA Account found in Active Directory
          CN=WebApp01,CN=Managed Service Accounts,DC=corp,DC=example,DC=com
  
  [PASS]  This Container (gmsa-test-webapp01-5bc485b8d5-9lbb7) is running on a GKE Windows Node that is authorized to use WebApp01
  
  [INFO]  Script execution complete at 01-05-2021-13:53:12
  
  *****      E N D   O F   D I A G N O S T I C S      *****
  

  La secuencia de comandos usa dos cmdlets de PowerShell para probar el acceso a la gMSA:

  • Get-ADServiceAccount: este cmdlet obtiene información sobre un gMSA. Si este cmdlet se ejecuta correctamente, el contenedor se estará ejecutando con una gMSA válida.
  • Test-ADServiceAccount: Este cmdlet comprueba si puede recuperar las credenciales de gMSA. Si el cmdlet se ejecuta correctamente, el contenedor se está ejecutando en un nodo de Windows Server que tiene permiso para acceder a las credenciales de gMSA.

Iniciar sesión de usuarios con la autenticación de Windows

1. En la barra de navegación superior de la página, haz clic en Iniciar sesión.
2. Cuando se te pida que introduzcas tus credenciales, escribe el nombre de usuario y la contraseña de tu dominio.

3. Si ves la página Seguro con la información de tu cuenta y no se te piden las credenciales, significa que tu navegador ha iniciado sesión automáticamente con tu identidad actual.

   Una vez que se haya autenticado, verá la página Segura. Asegúrate de que aparezcan las tres secciones siguientes:

   • Información del usuario: muestra tu nombre de usuario y el tipo de autenticación que se ha usado.
   • Grupos: muestra la lista de grupos a los que perteneces. Los nombres de los grupos de la lista se obtienen de Active Directory.
   • Reclamaciones de usuario: muestra la lista de reclamaciones del usuario tal como las proporciona Active Directory durante el inicio de sesión. Las reclamaciones de pertenencia a grupos muestran el SID del grupo de Active Directory, no sus nombres.

Además de admitir la autenticación integrada de Windows, la aplicación web ASP.NET puede usar su gMSA para la autenticación al llamar a servidores remotos. Con la gMSA, la aplicación web y cualquier otra aplicación que se ejecute en el contenedor de Windows pueden acceder a los recursos de la red que requieran autenticación de Windows, como las instancias de SQL Server y los recursos compartidos de red basados en SMB.

Solución de problemas

Si aparece algún mensaje de error durante el proceso de configuración o al probar la aplicación web, consulta las siguientes páginas para solucionar problemas:

• Solucionar problemas de Windows Server en GKE
• Documentación de Kubernetes sobre la solución de problemas de contenedores de Windows Server
• Documentación de Microsoft sobre la solución de problemas de gMSAs para contenedores de Windows

Consideraciones adicionales para las aplicaciones de producción

Las instrucciones que has seguido se han escrito para ofrecer una ruta óptima a los efectos del tutorial. En un entorno de producción, puede cambiar algunos de los procedimientos para que el resultado sea más sólido, tal como se describe en las siguientes secciones.

Consideraciones sobre los grupos de nodos de Windows Server

Si tienes previsto implementar tu propia aplicación que use una gMSA y la aplicación admite sesiones de cliente, te recomendamos que crees al menos dos nodos en el pool de nodos. Tener varios nodos te permite usar el almacenamiento de sesiones fuera del proceso para verificar que tu aplicación puede gestionar las sesiones distribuidas correctamente.

En este tutorial, crearás un grupo de nodos de Windows Server para alojar tus aplicaciones. Sin embargo, puede haber situaciones en las que quieras crear varios grupos de nodos de Windows Server en tu clúster. Por ejemplo, un grupo de nodos con discos persistentes (PDs) HDD y otro con PDs SSD. Si necesitas implementar tu aplicación en varios grupos de nodos, proporciona una matriz de objetos de grupo de Active Directory al parámetro PrincipalsAllowedToRetrieveManagedPassword cuando crees el gMSA con el cmdlet New-ADServiceAccount.

Consideraciones sobre gMSA y el nombre principal del servicio (SPN)

Si tu aplicación requiere que autentiques a los usuarios mediante Kerberos (por ejemplo, para admitir la delegación de identidad), debes acceder a tu aplicación mediante un DNS personalizado y configurar la gMSA con un nombre principal de servicio (SPN). Por ejemplo, si tu balanceador de carga expone la aplicación en GKE a través de https://my-web-app/, debes crear un SPN llamado HTTP/my-web-app de una de las siguientes formas:

• Para crear una gMSA, créala con los SPNs necesarios. Por ejemplo:

  New-ADServiceAccount -Name $GmsaName `
  -DNSHostName "$GmsaName.$AdDomain" `
  -PrincipalsAllowedToRetrieveManagedPassword $Groups `
  -ServicePrincipalNames "HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"
  

• En el caso de un gMSA, llama a Set-ADServiceAccount para añadir los SPNs necesarios al gMSA. Por ejemplo:

  Set-ADServiceAccount $GmsaName -ServicePrincipalNames @{Add="HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"}
  

Según tu configuración de DNS, también es posible que tengas que crear un SPN para HTTP/www.my-web-app y HTTP/www.my-web-app.$AdDomain.

En el caso de los protocolos que no son HTTP, como un servicio WCF configurado con un enlace TCP y la autenticación de Windows, es posible que tengas que crear otros tipos de SPNs, como un SPN HOST/.

Elegir la identidad del grupo de aplicaciones de IIS

Las aplicaciones web ASP.NET se ejecutan en Windows en el servidor web IIS. En IIS, puede configurar grupos de aplicaciones web que compartan el mismo proceso. Este grupo se denomina pool de aplicaciones. Cada grupo de aplicaciones se aloja en un proceso dedicado llamado w3wp. Los grupos de aplicaciones de IIS proporcionan la configuración de los procesos, como si el proceso es de 32 o 64 bits, y la identidad del proceso. Cuando ejecutas una aplicación web en un contenedor de Windows, debes configurar la identidad del proceso del grupo de aplicaciones para que use la cuenta Servicio de red integrada.

Las cuentas de identidad del grupo de aplicaciones local, que también admite IIS, no son necesarias en los contenedores de Windows. IIS creó las cuentas de identidad del grupo de aplicaciones para aplicar un límite de seguridad local cuando se ejecutan varias aplicaciones web en la misma instancia de IIS. Con los contenedores de Windows, en los que cada aplicación web se aloja en un contenedor independiente, no es necesario crear un límite de seguridad dentro del contenedor, ya que el propio contenedor proporciona el límite de seguridad.

Aunque la identidad del grupo de aplicaciones esté configurada para usar la cuenta de servicio de red, si la aplicación hace una solicitud a un recurso externo que requiere autenticación, la aplicación se autenticará mediante el gMSA que hayas configurado para el contenedor de Windows.