Implementa apps de ASP.NET con autenticación de Windows en contenedores de Windows para GKE

Estándar

En este instructivo, se muestra cómo crear una aplicación web ASP.NET que use IIS con autenticación integrada de Windows y cómo implementarla con un contenedor de Windows en un clúster de Google Kubernetes Engine (GKE) que tiene nodos de Windows Server unidos al dominio. Esta configuración es útil para implementar aplicaciones de ASP.NET en contenedores de Windows en Google Cloud a fin de que las aplicaciones puedan autenticarse en otros recursos de Windows. En el instructivo, también se muestra cómo crear una cuenta de servicio administrada (gMSA) de grupo en Active Directory y cómo configurar la implementación de la aplicación web en GKE para usarla.

Este instructivo está dirigido a los administradores del sistema. Se supone que estás familiarizado con Active Directory y que tienes experiencia en el trabajo con Google Kubernetes Engine (GKE).

Objetivos

Crea un clúster de GKE que tenga nodos de Windows Server unidos al dominio y configura el clúster para que admita gMSA de Active Directory.
Compilar e implementar una imagen de contenedor de aplicación web ASP.NET que use IIS con autenticación integrada de Windows.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Compute Engine
GKE
Artifact Registry
Otros costos asociados al instructivo relacionado Configura Active Directory para las VMs para que se unan automáticamente a un dominio:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Antes de comenzar

Sigue los pasos del instructivo Configura Active Directory para que las VM se unan automáticamente a un dominio a fin de crear el servicio de Cloud Run que se une a Active Directory.

Nota: No realices los pasos en la sección Limpieza, ya que usas la recursos de ese instructivo en este instructivo.
Si ejecutas este instructivo en un proyecto de Google Cloud diferente al que creaste una VM para probar la unión automática a dominios, realiza los pasos para habilitar un proyecto para la unión automática a dominios en tu proyecto de Google Cloud.

Cuando completes el otro instructivo, tendrás un nuevo servicio de Cloud Run y su URL se imprimirá en la ventana de PowerShell (el valor de la variable $RegisterUrl). Toma nota de la dirección del servicio, ya que la usarás en este instructivo.
Asegúrate de haber habilitado las APIs para Compute Engine, GKE, Cloud Build, Artifact Registry y la API de Cloud Resource Manager:

Habilita las APIs

Cuando finalices este instructivo, podrás borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta cómo hacer una limpieza.

Arquitectura

Las aplicaciones basadas en Windows que se ejecutan en un Windows Server unido al dominio suelen usar identidades de Microsoft Active Directory (AD) para autenticar usuarios y aplicaciones. Estos son algunos casos de uso comunes:

Crear aplicaciones web de ASP.NET que usen la autenticación integrada de Windows para autenticar a los usuarios de Active Directory mientras intentan acceder a la aplicación web
Crear aplicaciones que usen la cuenta de computadora de Active Directory del servidor para acceder a los recursos a través de la red, como una instancia remota de SMB o una instancia remota de Microsoft SQL Server

Los contenedores de Windows no pueden unirse a un dominio y, por lo tanto, no tienen cuentas de computadora en Active Directory. Debido a esto, 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 en la red. Para obtener más información sobre cómo ASP.NET accede a los recursos protegidos, consulta Identidades del grupo de aplicaciones en la documentación de Microsoft.

En lugar de usar una cuenta de computadora, los contenedores de Windows pueden usar una identidad de cuenta de servicio administrada de grupo (gMSA) de Active Directory para acceder a Active Directory y otros recursos protegidos en la red, como archivos compartidos e instancias de SQL Server. Para obtener más información, consulta la descripción general de las cuentas de servicio administradas de grupos en la documentación de Microsoft.

En el siguiente diagrama arquitectónico, se muestran los recursos que se usan en este instructivo:

Contenedores de Windows Server unidos a un dominio activo en GKE.

En el diagrama se muestran los siguientes elementos:

VM de desarrollo. En este instructivo, crearás una VM de Windows Server que usarás para compilar la imagen del contenedor de la aplicación web de ASP.NET y crear la gMSA.
Nodos y clúster de GKE. El clúster de GKE en este instructivo tiene un grupo de nodos de Linux y un grupo de nodos de Windows Server que se usan de las siguientes maneras:
- Los nodos de Linux ejecutan componentes de sistemas 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 se unen a un dominio de Active Directory.
Infraestructura de Active Directory A fin de que los nodos de Windows para GKE se unan al dominio, primero debes ejecutar el instructivo Configura Active Directory para las VM a fin de que se unan automáticamente a un dominio. En ese instructivo, crearás un servicio de Cloud Run que es responsable de registrar computadoras nuevas (instancias) en Active Directory y proporcionar a cada instancia nueva una contraseña temporal que la instancia usará para completar la unión a los dominios. Cada instancia nueva en el grupo de nodos de Windows Server llama al servicio de Cloud Run para unirse al dominio de Active Directory.
Balanceador de cargas de red. Cuando un usuario local abre su navegador y navega a la aplicación web ASP.NET, el tráfico pasa por un balanceador de cargas de red. GKE crea el balanceador de cargas cuando creas un servicio LoadBalancer de GKE para tu aplicación web. El usuario también se autentica en la aplicación web mediante el paso de sus credenciales de Active Directory a la aplicación web.

Crea la infraestructura

Una vez que hayas terminado el instructivo relacionado, crea los componentes de la infraestructura para el instructivo actual, que incluye lo siguiente:

Una VM de Windows Server que tiene una imagen de contenedor de aplicaciones web de ASP.NET
Un clúster de GKE que tenga un grupo de nodos de Windows Server
Reglas de firewall que otorgan a los pods de GKE acceso a Active Directory.
Un webhook en el clúster de GKE que controla la configuración y la propagación de los recursos de gMSA en las implementaciones

Crea 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 compilas 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. Crear una imagen de contenedor o ejecutar un contenedor en una versión diferente de Windows Server genera un error. Para obtener más información sobre los requisitos de compatibilidad de los contenedores de Windows, consulta Coincidencia de versiones de host de contenedor con versiones de imágenes de contenedor.

En este instructivo, se usa la versión del canal de servicio a largo plazo (LTSC) 2022 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 versiones de Windows Server y de GKE.

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Si PowerShell está abierto, escribe exit para cerrarlo.
Configura las variables de entorno para el nombre de la red y la subred, y 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
```
Reemplaza lo siguiente:
- NETWORK-NAME: La red de VPC en la que se implementarán las VM.
- SUBNETWORK-NAME: Es la subred en la que se implementarán las VM.
- AD-JOIN-SERVICE-URL: Es la URL del servicio de Cloud Run que implementaste en la sección Antes de comenzar.
Configura el ID del proyecto de Google Cloud y la región para el entorno actual:
```
gcloud config set project PROJECT-ID
gcloud config set compute/zone ZONE-NAME
```
Reemplaza lo siguiente:
- PROJECT-ID: es el ID del proyecto de Google Cloud.
- ZONE-NAME: Es la zona en la que se implementarán todas las VM. Para reducir la latencia, te recomendamos que selecciones una zona en la misma región en la que implementaste el servicio de Cloud Run de unión al dominio de Active Directory.

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.iam.gserviceaccount.com

gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \
    --display-name="Development VM Service Account"

Otorga a la cuenta de servicio acceso a Artifact Registry:

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

Otorga 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"
```
La cuenta de servicio recibe la función container.admin, porque esta función tiene permisos para crear clústeres de GKE en el proyecto y administrar recursos en clústeres, incluidos los recursos de control de acceso basados en funciones (RBAC). Los recursos de RBAC son necesarios para controlar qué pod puede usar una gMSA.
Crea una VM nueva 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"
```
Nota: Si las VMs de tu VPC tienen formas de acceder a Internet sin una dirección IP externa, como Cloud NAT, puedes quitar la dirección IP externa o agregar el parámetro --no-address al comando antes de ejecutarlo.

Si planeas implementar tus aplicaciones en contenedores en contenedores de Windows Server 2019, cambia 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 de Google Cloud, según los roles de IAM que se definen para la cuenta de servicio de la instancia.

La VM se crea con una dirección IP externa para permitir que se comunique con Internet. Necesitas que la VM tenga acceso a Internet para poder descargar varias utilidades, como git y kubectl, y para descargar la aplicación web de ASP.NET desde GitHub.

Durante la etapa sysprep, la instancia nueva se une al dominio de Active Directory para permitirte acceder a la instancia de forma remota mediante la cuenta de dominio. La secuencia de comandos en el comando sysprep también instala el módulo de PowerShell para Active Directory.

Crea un repositorio de Docker de Artifact Registry

En Cloud Shell, configura la ubicación predeterminada para los repositorios nuevos de Artifact Registry:
```
gcloud config set artifacts/location LOCATION
```
Reemplaza LOCATION por una región en la que deseas crear el repositorio de Artifact Registry. Para reducir la latencia, te recomendamos que selecciones la misma región en la que implementaste la VM de desarrollo.

Crea el repositorio de Artifact Registry Docker:

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

Crear un clúster de GKE

En Cloud Shell, establece una variable de entorno para el nombre del clúster de GKE:
```
export GKE_CLUSTER_NAME=cluster-1
```
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 configuras el parámetro --release-channel como rapid, se implementa el clúster de GKE con la última versión de Kubernetes. El parámetro --enable-ip-alias activa el IP de alias. El IP de alias es obligatorio para los nodos de Windows Server.

Crea un grupo de nodos de Windows Server en GKE

Cuando creas un clúster de GKE nuevo 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.

En Cloud Shell, configura una variable de entorno para el nombre del grupo de nodos del servidor de Windows:
```
export NODE_POOL_NAME=windows-server-pool
```
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 planeas implementar tus aplicaciones en contenedores en contenedores de Windows Server 2019, cambia el parámetro --windows-os-version a 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 desde el servicio de unión a dominios de Active Directory que implementaste en Cloud Run. Luego, ejecuta la secuencia de comandos que une la instancia nueva al dominio de Active Directory.

El parámetro --no-enable-autoupgrade inhabilita la actualización automática de nodos para todos los nodos del grupo. Para ello, la actualización de la imagen de Windows de un nodo puede generar 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 Actualiza grupos de nodos de Windows Server.

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

Espera varios minutos hasta que se cree el grupo de nodos y, luego, ejecuta el siguiente comando para verificar que todos los nodos se hayan 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 unieron 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 deseas ver el resultado completo de la secuencia de comandos, quita .*success del comando grep.

Otorga a los pods de GKE acceso a Active Directory

Debes crear una regla de firewall que permita que los Pods del clúster de GKE accedan a los 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)
LDAP GC (TCP/3268)
Servicios web de Active Directory (TCP/9389)

Puedes aplicar la regla según una cuenta de servicio que hayas asignado a los controladores de dominio, o bien puedes aplicarla mediante una etiqueta de red, como se indica en este instructivo. Para obtener más información sobre los puertos relacionados con Active Directory, consulta la documentación sobre Requisitos de protocolos y puertos de Active Directory y Usa Active Directory entre firewalls.

Si usas el Servicio administrado para Microsoft Active Directory (Microsoft AD administrado), puedes omitir este procedimiento.

En Cloud Shell, obtén el rango de direcciones IP del pod del clúster de GKE:

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

Crea una regla de firewall para otorgar a los pods de GKE acceso 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

Reemplaza DC-TAG por la etiqueta de red que se asigna a las VM de tus controladores de dominio.

Configura GKE para que admita el uso de gMSA

A fin de 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 recuperar sus credenciales de gMSA.

En Cloud Shell, descarga y ejecuta la secuencia de comandos de 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 agrega el manifiesto de definición de recursos personalizado (CRD) de gMSA a tu clúster de GKE y, luego, implementa un webhook que proporciona las especificaciones de gMSA a los pods. Ahora puedes almacenar especificaciones de gMSA en tu clúster, y configurar gMSA para pods y contenedores.

Si deseas obtener más información sobre Kubernetes y gMSA, consulta Configura GMSA para contenedores y pods de Windows.

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

Integra en Active Directory

A continuación, crea una gMSA para la aplicación web de ASP.NET en Active Directory, configura cómo y quién puede usarlo y quién, y luego agrega su configuración a GKE.

Accede y, luego, inicia PowerShell

Conéctate a la VM gmsa-dev-vm.
Accede a Windows con una cuenta de Active Directory que tenga permiso para crear una gMSA.

Tu cuenta debe ser miembro del grupo Domain Admins o debe poder crear objetos msDS-GroupManagedServiceAccount. Para obtener más información, consulta Aprovisiona cuentas de servicio administradas de grupo.

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 Delega la administración de cuentas de servicio administradas.
Escribe 15 para salir del menú a la línea de comandos (PowerShell).

Instala el entorno de ejecución de un contenedor

Windows Server 2022 requiere un entorno de ejecución del contenedor, como Docker Community Edition (CE) para crear y ejecutar contenedores de Windows. Si deseas obtener más información para instalar un entorno de ejecución de contenedores en Windows Server, consulta Primeros pasos: Prepara Windows para contenedores en la documentación de Microsoft.

Si creaste la VM de desarrollo con la imagen windows-2019-core-for-containers, puedes omitir el siguiente procedimiento, porque la imagen ya tiene Docker instalado.

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 durante el proceso de instalación se cierra la conexión de escritorio remoto, vuelve a conectarte a la VM.

Espera a que se complete el proceso de instalación y, luego, escribe exit para cerrar la nueva ventana de PowerShell.
Escribe 15 para salir del menú a la línea de comandos (PowerShell).

Crea una clave raíz KDS

Antes de crear una gMSA, debes asegurarte de que el 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 a fin de generar contraseñas para gMSA.

Si estás utilizando Managed Microsoft AD, puedes omitir el siguiente procedimiento porque Managed Microsoft AD crea la clave raíz de KDS cuando creas el dominio.

En gmsa-dev-vm, verifica si Active Directory ya tiene la clave raíz de KDS:
```
Get-KdsRootKey
```
Este comando muestra el ID de la clave, si existe.

Si no obtienes un ID de clave en respuesta, crea la clave:

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

Crea la gMSA

Cuando creas una gMSA, debes proporcionar los nombres de las computadoras que tienen acceso a gMSA. Como práctica recomendada de seguridad, debes otorgar permiso a gMSA solo a las instancias en las que se ejecuta tu aplicación. Cuando creas un grupo de nodos de Windows Server unido al dominio, se crea un grupo de Active Directory nuevo para las computadoras del grupo de nodos. El nombre del grupo coincide con el nombre del grupo de instancias administrado (MIG) que GKE crea para el grupo de nodos.

En PowerShell, configura las variables para el ID del proyecto de Google Cloud, el nombre del clúster, el nombre del grupo de nodos de Windows, el nombre de gMSA y el nombre de dominio de AD:
```
$ProjectId = "PROJECT-ID"
$GkeClusterName = "cluster-1"
$PermittedNodePool = "windows-server-pool"
$GmsaName = "WebApp-01"
$AdDomain = (Get-ADDomain).DNSRoot
```
Reemplaza PROJECT-ID por el ID del proyecto de Google Cloud.
Establece la configuración del clúster para la herramienta de gcloud:
```
gcloud config set project $ProjectId
gcloud config set compute/zone "ZONE-NAME"
```
Reemplaza ZONE-NAME por la zona en la que implementaste el clúster de GKE.

Recupera el nombre de dominio del grupo de Active Directory que se creó 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

Crea la gMSA:

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

Verifica que se haya creado la gMSA:

Get-ADServiceAccount -Identity $GmsaName

Si se creó la gMSA, el resultado es 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 :

Agrega 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 usarlo.

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"

Instala la herramienta de 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"

Instala el objeto binario gke-gcloud-auth-plugin:
```
gcloud components install gke-gcloud-auth-plugin
```
Espera varios minutos para que finalice el proceso de instalación.
Inicializa la herramienta de kubectl con las credenciales de tu clúster de GKE:
```
gcloud container clusters get-credentials $GkeClusterName
```
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úscula.

La secuencia de comandos cambia el uso de mayúsculas de la variable $GmsaName para cumplir con esta restricción.

La secuencia de comandos muestra un mensaje de advertencia que indica que la cuenta de servicio administrada falló, que es lo que se espera. La 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 las credenciales gMSA.
Agrega la especificación de credenciales gMSA al clúster de GKE:
```
kubectl apply -f $CredSpecFile
```

Clona el repositorio de GitHub:

git clone https://github.com/GoogleCloudPlatform/gke-aspnet-gmsa.git
cd gke-aspnet-gmsa

Agrega los objetos de RBAC de gMSA a tu clúster:
```
kubectl apply -f gmsa-rbac-webapp-01.yaml
```
gmsa-rbac-webapp-01.yaml crea un objeto RBAC de ClusterRole para la gMSA y, luego, vincula el rol del clúster nueva a la cuenta de servicio predeterminada en el espacio de nombres default. Si implementas tu aplicación en un espacio de nombres diferente, edita el archivo gmsa-rbac-webapp-01.yaml y cambia el espacio de nombres para la vinculación de función y la cuenta de servicio.

Implementa y usa la aplicación web

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

Compila e implementa la aplicación web de ASP.NET

En gmsa-dev-vm, en PowerShell, configura las variables para la ubicación del registro, el nombre del registro y la etiqueta de imagen:
```
$RegistryLocation = "LOCATION-docker.pkg.dev"
$ProjectsRegistry = "$RegistryLocation/$ProjectId"
$ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
```
Reemplaza LOCATION por la ubicación en la que creaste el repositorio de Artifact Registry.
Compila la imagen del contenedor:
```
docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
```
Si quieres compilar imágenes de contenedor para Windows Server 2019, configura el valor del parámetro -f como Dockerfile-WINDOWS_LTSC2019.

Envía la imagen del contenedor a Artifact Registry

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

Descarga el archivo YAML de la aplicación y actualízalo con la 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.
Implementa la aplicación web en el clúster de GKE:
```
kubectl apply -f $ApplicationYaml
```

Verifica que se esté ejecutando la aplicación web de ASP.NET

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

Verifica 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 permanece como Pending y no cambia a ContainerCreating o Running, verifica el imagen de origen de tu nodo de Windows para asegurarte de que sea Windows Server 2022. También puedes verificar la tabla de asignación de versiones para ver cómo se asignan las versiones de GKE a las versiones de Windows Server. Si las versiones no coinciden, duplica el archivo Dockerfile-WINDOWS_LTSC2022, configura la imagen de contenedor base en el archivo nuevo para que coincida con la versión de Windows Server de tus nodos. y, luego, repite los pasos para compilar e implementar la aplicación web ASP.NET.

Verifica 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

Tome nota del valor external-ip en el resultado. Necesitas este valor más tarde.

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

El Pod ahora se está ejecutando y se puede acceder a él desde Internet a través de un balanceador de cargas de red. A continuación, ejecuta pruebas preliminares a fin de verificar que el contenedor se haya implementado de forma correcta y que tenga permisos para usar la gMSA.

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

Reemplaza EXTERNAL-IP por la dirección IP que obtuviste en el procedimiento anterior.

Desplázate hasta la sección Verificaciones preliminares y haz clic en el botón Ejecutar verificaciones preliminares para verificar que se hayan aprobado todas las pruebas.

Si las pruebas se aprueban, 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.

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

Usa la gMSA en contenedores de Windows

Ahora puedes verificar que la configuración de gMSA funcione correctamente mediante la ejecución de varias pruebas en la aplicación web. Cada una de las pruebas usa gMSA para un propósito diferente. Si todas las pruebas se completaron correctamente, entonces configuraste gMSA de manera correcta.

Valida la configuración de contenedor de gMSA

Desplázate hasta la sección Conectividad del dominio, escribe el nombre de tu gMSA (WebApp-01) en el cuadro Nombre de la cuenta y, luego, haz clic en Ejecutar secuencia de comandos. Espera unos segundos para que finalicen las pruebas.

El resultado es 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 gMSA:
- Get-ADServiceAccount: Este cmdlet recupera información sobre una gMSA. Si este cmdlet se ejecuta correctamente, el contenedor se ejecuta con una gMSA válida.
- Test-ADServiceAccount: Este cmdlet prueba si puede recuperar las credenciales de gMSA. Si el cmdlet se ejecuta correctamente, el contenedor se ejecuta en un nodo de Windows Server que tiene acceso a las credenciales de gMSA.

Permite que los usuarios accedan con la autenticación de Windows

En la barra de navegación superior de la página, haz clic en Acceder.
Cuando se te solicite que ingreses tus credenciales, ingresa el nombre de usuario y la contraseña del dominio.
Si ves la página Proteger con la información de tu cuenta y no se te solicitan credenciales, tu navegador te registró automáticamente con tu identidad actual.

Una vez autenticado, verás la página Proteger. Asegúrate de ver las siguientes tres secciones:
- Información del usuario: Muestra tu nombre de usuario y el tipo de autenticación que se usó.
- Grupos: Muestra la lista de grupos a los que perteneces. Los nombres de grupos de la lista se recuperan de Active Directory.
- Reclamaciones de usuarios: Muestra la lista de reclamaciones para el usuario según lo proporciona Active Directory durante el acceso. Las reclamaciones de membresía del grupo muestran el SID de Active Directory Group, no sus nombres.

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

Soluciona problemas

Si encuentras algún mensaje de error durante el proceso de configuración o mientras pruebas la aplicación web, consulta las siguientes páginas de solución de problemas:

Soluciona problemas de Windows Server en GKE
Documentación de Kubernetes sobre cómo solucionar problemas de contenedores de Windows Server
Documentación de Microsoft sobre la solución de problemas de gMSA para contenedores de Windows

Consideraciones adicionales para las aplicaciones de producción

Las instrucciones que seguiste se escribieron a fin de proporcionar una ruta óptima para los fines del instructivo. En un entorno de producción, puedes realizar cambios en algunos de los procedimientos para que el resultado sea más sólido, como se describe en las siguientes secciones.

Consideraciones sobre los grupos de nodos de Windows Server

Si planeas implementar tu propia aplicación que usa una gMSA y la aplicación admite sesiones de cliente, te recomendamos que crees al menos dos nodos en el grupo de nodos. Tener varios nodos te permite usar el almacenamiento de sesión fuera del proceso para verificar que tu aplicación pueda manejar las sesiones distribuidas correctamente.

En este instructivo, crearás un único grupo de nodos de Windows Server para alojar tus aplicaciones. Sin embargo, puede haber situaciones en las que desees crear varios grupos de nodos de Windows Server en tu clúster, por ejemplo, un grupo de nodos con discos persistentes HDD (PD) y otro grupo de nodos con PD SSD. Si necesitas implementar tu aplicación en varios grupos de nodos, proporciona un array de objetos de grupo de Active Directory para el parámetro PrincipalsAllowedToRetrieveManagedPassword cuando creas la gMSA el cmdlet New-ADServiceAccount.

Consideraciones sobre la gMSA y el nombre principal de servicio (SPN)

Si tu aplicación requiere que autentiques usuarios con Kerberos (por ejemplo, para admitir la delegación de identidades), debes acceder a tu aplicación mediante un DNS personalizado y configurar el gMSA con un nombre principal del servicio (SPN). Por ejemplo, si el balanceador de cargas 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 maneras:

Para una gMSA nueva, crea la gMSA con los SPN 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 una gMSA, llama a Set-ADServiceAccount para agregar los SPN necesarios a la gMSA. Por ejemplo:

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

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

Para los protocolos que no son HTTP, como un servicio WCF configurado con la vinculación TCP y la autenticación de Windows, es posible que debas crear otros tipos de SPN, como un SPN HOST/.

Elige la identidad del grupo de aplicaciones de IIS

Las aplicaciones web de ASP.NET se ejecutan en Windows en el servidor web de IIS. En IIS, configuras grupos de aplicaciones web que comparten el mismo proceso. Este grupo se denomina grupo de aplicaciones. Cada grupo de aplicaciones se aloja en un proceso dedicado llamado w3wp. Los grupos de aplicaciones IIS proporcionan configuración del proceso, por ejemplo, si el proceso es de 32 bits o de 64 bits, y proporcionan 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 usar la cuenta integrada de Network Service.

Las cuentas locales de identidad del grupo de aplicaciones, que IIS también admite, no son necesarias en los contenedores de Windows. IIS creó las cuentas de identidad del grupo de aplicaciones como un medio 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 separado, no es necesario crear un límite de seguridad dentro del contenedor, ya que el contenedor en sí 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 realiza una solicitud a un recurso externo que requiere autenticación, la aplicación se autentica mediante la gMSA que configuraste para el contenedor de Windows

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Quita recursos individuales

Si deseas conservar tu proyecto de Google Cloud, pero no quieres borrar los recursos de Google Cloud que creaste para este instructivo, puedes quitar los recursos de forma individual.

Revierte los cambios de Active Directory

Conéctate a la VM de desarrollo y accede como un usuario que tenga acceso de administrador al dominio de Active Directory.
En la VM gmsa-dev-vm, si PowerShell aún no está abierto, ábrelo:
```
PowerShell
```

Borra la gMSA:

Remove-ADServiceAccount -Identity "WebApp-01" -Confirm:$false

Borra recursos de la nube

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell
Inicializa el entorno gcloud:
```
gcloud config set project PROJECT-ID
gcloud config set compute/zone ZONE-NAME
gcloud config set artifacts/location LOCATION
```
Reemplaza lo siguiente:
- PROJECT-ID: es el ID del proyecto de Google Cloud.
- ZONE-NAME: La zona en la que implementaste el clúster de GKE y la VM de desarrollo.
- LOCATION: La región en la que implementaste el repositorio de Artifact Registry.

Borra la VM de desarrollo:

gcloud compute instances delete gmsa-dev-vm --quiet

Borra la cuenta de servicio:

gcloud iam service-accounts delete dev-vm@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --quiet

Borra el clúster de GKE:

gcloud container clusters delete cluster-1 --quiet

Si creaste una regla de firewall para tus controladores de Active Directory, bórrala:
```
gcloud compute firewall-rules delete allow-gke-pods-to-ad --quiet
```

Borra el repositorio de Docker de Artifact Registry

gcloud artifacts repositories delete windows-container-images --quiet

Para finalizar, sigue los pasos de limpieza en Configura Active Directory para que las VMs se unan automáticamente a un dominio.

¿Qué sigue?

Obtén más información sobre los contenedores de Windows Server en GKE.
Obtén más información sobre cómo crear un clúster de GKE con grupos de nodos de Windows Server.
Lee sobre otras formas de implementar aplicaciones de Windows Server.
Revisa nuestras prácticas recomendadas para implementar un bosque de recursos de Active Directory en Google Cloud.
Explora las secuencias de comandos de prueba que usa la aplicación web de ASP.NET en GitHub.