Esegui il deployment di app ASP.NET con autenticazione Windows nei container GKE Windows

Standard

Questo tutorial mostra come creare un'applicazione web ASP.NET che utilizza IIS con l'autenticazione integrata di Windows, e come eseguirne il deployment utilizzando un container Windows in un cluster Google Kubernetes Engine (GKE) con nodi Windows Server aggiunti al dominio. Questa configurazione è utile per il deployment di applicazioni ASP.NET in container Windows su Google Cloud in modo che le applicazioni possano autenticarsi ad altre risorse Windows. Il tutorial mostra anche come creare un service account gestito dal gruppo (gMSA) in Active Directory e come configurare il deployment dell'applicazione web in GKE per utilizzarlo.

Questo tutorial è rivolto agli amministratori di sistema. Si presuppone che tu conosca Active Directory e abbia esperienza con Google Kubernetes Engine (GKE).

Nota: questo tutorial richiede il completamento di un tutorial correlato, Configurazione di Active Directory per consentire alle VM di unirsi automaticamente a un dominio, come spiegato più avanti in questo documento.

Obiettivi

• Crea un cluster GKE con nodi Windows Server aggiunti al dominio e configura il cluster in modo che supporti i gMSA di Active Directory.
• Crea ed esegui il deployment di un'immagine container di un'applicazione web ASP.NET che utilizza IIS con l'autenticazione Windows integrata.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Compute Engine
• GKE
• Artifact Registry
• Other costs that are associated with the related tutorial Configuring Active Directory for VMs to automatically join a domain:
  • Serverless VPC Access
  • Cloud Run
  • Artifact Registry
  • Secret Manager
  • Cloud Scheduler

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Prima di iniziare

1. Segui i passaggi del tutorial Configura Active Directory per consentire alle VM di unirsi automaticamente a un dominio per creare il servizio Cloud Run per l'unione al dominio Active Directory.

   Nota: non eseguire i passaggi della sezione Pulizia, perché in questo tutorial utilizzi le risorse di quel tutorial.

2. Se esegui questo tutorial in un progetto Google Cloud diverso da quello in cui hai creato una VM per testare l'aggiunta automatica al dominio, esegui i passaggi per attivare un progetto per l'aggiunta automatica al dominio nel tuo progetto Google Cloud .

   Al termine dell'altro tutorial, avrai un nuovo servizio Cloud Run e il relativo URL verrà stampato nella finestra di PowerShell (il valore della variabile $RegisterUrl). Prendi nota dell'indirizzo del servizio, perché lo utilizzerai in questo tutorial.

3. Assicurati di aver abilitato le API per Compute Engine, GKE, Cloud Build, Artifact Registry e Cloud Resource Manager:

   Abilita le API

   Al termine di questo tutorial, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per ulteriori informazioni, vedi Pulizia.

Architettura

Le applicazioni basate su Windows eseguite in un Windows Server aggiunto al dominio spesso utilizzano le identità di Microsoft Active Directory (AD) per autenticare utenti e applicazioni. I casi d'uso comuni sono i seguenti:

• Creazione di applicazioni web ASP.NET che utilizzano l'autenticazione integrata di Windows per autenticare gli utenti di Active Directory quando tentano di accedere all'applicazione web.
• Creazione di applicazioni che utilizzano l'account computer Active Directory del server per accedere alle risorse sulla rete, ad esempio una condivisione SMB remota o un'istanza Microsoft SQL Server remota.

I container Windows non possono essere uniti a un dominio e pertanto non dispongono di account computer in Active Directory. Per questo motivo, le applicazioni web ASP.NET in esecuzione su container Windows non possono autenticare gli utenti di Active Directory tramite l'autenticazione integrata di Windows e pertanto non possono accedere alle risorse protette nella rete. Per saperne di più su come ASP.NET accede alle risorse protette, consulta Identità dei pool di applicazioni nella documentazione di Microsoft.

Anziché utilizzare un account computer, i container Windows possono utilizzare un'identità di account del servizio gestito (gMSA) di Active Directory per accedere ad Active Directory e ad altre risorse protette nella rete, come condivisioni di file e istanze di SQL Server. Per saperne di più, consulta la panoramica dei service account gestiti dal gruppo nella documentazione di Microsoft.

Il seguente diagramma dell'architettura mostra le risorse utilizzate in questo tutorial:

Il diagramma mostra i seguenti elementi:

• VM di sviluppo. In questo tutorial, creerai una VM Windows Server che utilizzerai per creare l'immagine container dell'applicazione web ASP.NET e per creare la gMSA.
• Cluster e nodi GKE. Il cluster GKE in questo tutorial ha un node pool Linux e un pool di nodi Windows Server che vengono utilizzati nei seguenti modi:
  • I nodi Linux eseguono componenti di sistema che vengono eseguiti solo sui sistemi operativi Linux, come il server delle metriche GKE.
  • I nodi Windows Server vengono utilizzati per ospitare i container Windows Server e sono uniti a un dominio Active Directory.
• Infrastruttura Active Directory. Per fare in modo che i nodi GKE Windows vengano aggiunti al dominio, segui prima il tutorial Configurazione di Active Directory per consentire alle VM di unirsi automaticamente a un dominio. In questo tutorial, crei un servizio Cloud Run responsabile della registrazione di nuovi computer (istanze) in Active Directory e della fornitura a ogni nuova istanza di una password temporanea che l'istanza utilizza per completare il processo di unione al dominio. Ogni nuova istanza nel pool di nodi Windows Server chiama il servizio Cloud Run per unirsi al dominio Active Directory.
• Bilanciatore del carico di rete. Quando un utente on-premise apre il browser e naviga nell'applicazione web ASP.NET, il traffico passa attraverso un bilanciatore del carico di rete. Il bilanciatore del carico viene creato da GKE quando crei un servizio LoadBalancer GKE per la tua applicazione web. L'utente esegue anche l'autenticazione all'applicazione web trasmettendo le proprie credenziali di Active Directory all'applicazione web.

Creazione dell'infrastruttura

Dopo aver completato il tutorial correlato, crea i componenti dell'infrastruttura per il tutorial corrente, che include quanto segue:

• Una VM Windows Server con un'immagine container dell'applicazione web ASP.NET.
• Un cluster GKE con un pool di nodi Windows Server.
• Regole firewall che concedono ai pod GKE l'accesso ad Active Directory.
• Un webhook nel cluster GKE che gestisce la configurazione e il popolamento delle risorse gMSA nei deployment.

Crea una VM di sviluppo

L'immagine container Windows Server che crei deve corrispondere alla versione di Windows Server della VM in cui crei l'immagine container. Questa versione deve corrispondere anche alla versione di Windows Server dei nodi GKE Windows Server. La creazione di un'immagine container o l'esecuzione di un container in una versione diversa di Windows Server genera un errore. Per ulteriori informazioni sui requisiti di compatibilità dei container Windows, consulta Corrispondenza tra la versione dell'host container e le versioni delle immagini container.

Questo tutorial utilizza la versione Long-Term Servicing Channel (LTSC) 2022 di Windows Server per la VM, i nodi Windows Server in GKE e l'immagine container. Per saperne di più, consulta la mappatura delle versioni tra le versioni di Windows Server e le versioni di GKE.

Nota: se prevedi di utilizzare più versioni di Windows Server nel cluster GKE, puoi creare immagini multi-architettura di Windows Server. Questo tutorial non tratta questo argomento.

1. Nella console Google Cloud , attiva Cloud Shell.

   Attiva Cloud Shell

   Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

2. Se PowerShell è aperto, chiudilo digitando exit.

3. Imposta le variabili di ambiente per il nome della rete e della subnet e per l'URL del servizio di directory Active Directory:

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

   Sostituisci quanto segue:

   • NETWORK-NAME: La rete VPC in cui eseguire il deployment delle VM.
   • SUBNETWORK-NAME: La subnet in cui eseguire il deployment delle VM.
   • AD-JOIN-SERVICE-URL: l'URL del servizio Cloud Run di cui hai eseguito il deployment nella sezione Prima di iniziare.

4. Imposta l'ID progetto Google Cloud e la regione per l'ambiente corrente:

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

   Sostituisci quanto segue:

   • PROJECT-ID: l'ID progetto Google Cloud .
   • ZONE-NAME: la zona in cui eseguire il deployment di tutte le VM. Per ridurre la latenza, ti consigliamo di selezionare una zona nella stessa regione in cui hai eseguito il deployment del servizio Cloud Run per l'aggiunta al dominio Active Directory.

5. Crea un account di servizio per la VM di sviluppo:

   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"
   

6. Concedi al account di servizio l'accesso ad Artifact Registry:

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

7. Concedi al account di servizio l'accesso a GKE:

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

   Al account di servizio viene concesso il ruolo container.admin perché questo ruolo dispone delle autorizzazioni per creare cluster GKE nel progetto e per gestire le risorse nei cluster, incluse le risorse di controllo dell'accesso basato su ruoli (RBAC). Le risorse RBAC sono necessarie per controllare a quale pod è consentito utilizzare un gMSA.

8. Crea una nuova VM 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: se le VM nel tuo VPC hanno modi per accedere a internet senza un indirizzo IP esterno, ad esempio utilizzando Cloud NAT, puoi rimuovere l'indirizzo IP esterno o aggiungere il parametro --no-address al comando prima di eseguirlo.

   Se prevedi di eseguire il deployment delle applicazioni in container nei container Windows Server 2019, modifica il valore parametro --image-family in windows-2019-core-for-containers.

   L'ambito https://www.googleapis.com/auth/cloud-platform consente all'istanza di accedere a tutte le API Google Cloud , a seconda dei ruoli IAM definiti per il account di servizio dell'istanza.

   La VM viene creata con un indirizzo IP esterno per consentirle di comunicare con internet. La VM deve avere accesso a internet per poter scaricare diverse utilità, come git e kubectl, e per scaricare l'applicazione web ASP.NET da GitHub.

   Durante la fase sysprep, la nuova istanza viene unita al dominio Active Directory per consentirti di accedervi da remoto utilizzando l'account di dominio. Lo script nel comando sysprep installa anche il modulo PowerShell per Active Directory.

Crea un repository Docker Artifact Registry

1. In Cloud Shell, imposta la località predefinita per i nuovi repository Artifact Registry:

   gcloud config set artifacts/location LOCATION
   

   Sostituisci LOCATION con una regione in cui vuoi creare il repository Artifact Registry. Per ridurre la latenza, ti consigliamo di selezionare la stessa regione in cui hai eseguito il deployment della VM di sviluppo.

2. Crea il repository Docker di Artifact Registry:

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

Crea un cluster GKE

1. In Cloud Shell, imposta una variabile di ambiente per il nome del cluster GKE:

   export GKE_CLUSTER_NAME=cluster-1
   

2. Crea il cluster GKE:

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

   L'impostazione del parametro --release-channel su rapid esegue il deployment del cluster GKE con l'ultima versione di Kubernetes. Il parametro --enable-ip-alias attiva gli IP alias. L'IP alias è obbligatorio per i nodi Windows Server.

Crea un pool di nodi Windows Server in GKE

Quando crei un nuovo cluster GKE tramite la CLI, il cluster viene creato con unpool di nodil Linux. Per utilizzare Windows Server su GKE, crea unpool di nodil Windows Server.

I cluster GKE devono avere almeno un nodo Linux per eseguire i container interni (di sistema) del cluster. Non è possibile creare un cluster GKE solo con nodi Windows Server.

1. In Cloud Shell, imposta una variabile di ambiente per il nome del pool di nodi del server Windows:

   export NODE_POOL_NAME=windows-server-pool
   

2. Crea un pool di nodi GKE Windows Server:

   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'))"
   

   Se prevedi di eseguire il deployment delle applicazioni containerizzate nei container Windows Server 2019, modifica il parametro --windows-os-version in ltsc2019.

   La chiave dei metadati sysprep-specialize-script-ps1 è una chiave integrata che rimanda a uno script PowerShell eseguito durante il passaggio GCESysprep, prima del primo avvio dell'istanza.

   Il cmdlet iex scarica lo script PowerShell dal servizio di unione al dominio Active Directory che hai eseguito il deployment su Cloud Run. Quindi, esegue lo script che unisce la nuova istanza al dominio Active Directory.

   Il parametro --no-enable-autoupgrade disabilita l'upgrade automatico dei nodi per tutti i nodi nel pool. Lo fa perché l'upgrade di un'immagine Windows di un nodo può causare incompatibilità tra la versione di Windows Server del nodo e quella del pod. Per saperne di più, consulta Upgrade dei pool di nodi Windows Server.

   Dopo la creazione di ogni nodo, lo script PowerShell domain-join unisce il nodo al dominio.

3. Attendi alcuni minuti fino alla creazione del pool di nodi, poi esegui il comando seguente per verificare che tutti i nodi abbiano eseguito l'accesso 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
   

   Se i nodi sono stati uniti al dominio, l'output è il seguente:

   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.
   

   Se vuoi visualizzare l'output completo dello script, rimuovi .*success dal comando grep.

Concedi ai pod GKE l'accesso ad Active Directory

Devi creare una regola firewall che consenta ai pod del cluster GKE di accedere ai controller di dominio utilizzando i seguenti protocolli:

• 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)
• Servizi web Active Directory (TCP/9389)

Puoi applicare la regola in base a un account di servizio che hai assegnato ai domain controller oppure puoi applicarla utilizzando un tag di rete, come in questo tutorial. Per scoprire di più sulle porte relative ad Active Directory, consulta la documentazione sui requisiti di porte e protocolli di Active Directory e sull'utilizzo di Active Directory con firewall.

Se utilizzi Managed Service for Microsoft Active Directory (Managed Microsoft AD), puoi saltare questa procedura.

1. In Cloud Shell, recupera l'intervallo di indirizzi IP dei pod del cluster GKE:

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

2. Crea una regola firewall per consentire ai pod GKE di accedere ad 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
   

   Sostituisci DC-TAG con il tag di rete assegnato alle VM dei controller di dominio.

Configura GKE per supportare l'utilizzo degli MSA di gruppo

Per utilizzare un gMSA nei nodi Windows Server, devi creare l'oggetto gMSA in Active Directory, creare una risorsa gMSA corrispondente in GKE e consentire ai pod appena creati di recuperare le proprie credenziali gMSA.

1. In Cloud Shell, scarica ed esegui lo script webhook 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
   

   Lo script aggiunge il manifest della definizione di risorsa personalizzata (CRD) gMSA al tuo cluster GKE e ne esegue il deployment di un webhook che fornisce le specifiche gMSA ai pod. Ora puoi archiviare le specifiche gMSA nel cluster e configurare i gMSA per pod e container.

   Per scoprire di più su Kubernetes e sui gMSA, consulta Configura GMSA per pod e container Windows.

Il cluster GKE è ora pronto per eseguire applicazioni Windows che richiedono l'utilizzo di un account di servizio gestito da gruppo. Ad esempio, puoi eseguire un'applicazione web ASP.NET nei nodi Windows Server. Puoi configurare l'applicazione per consentire agli utenti di accedere con l'autenticazione di Windows o fare in modo che l'applicazione utilizzi il gMSA del pod per accedere a una condivisione di rete remota o a un database SQL Server.

Integrazione con Active Directory

Successivamente, crei un gMSA per la tua applicazione web ASP.NET in Active Directory, configuri come e da chi può essere utilizzato e poi aggiungi la sua configurazione a GKE.

Accedi e avvia PowerShell

1. Connettiti alla VM gmsa-dev-vm.

2. Accedi a Windows utilizzando un account Active Directory autorizzato a creare un gMSA.

   Il tuo account deve essere un membro del gruppo Domain Admins o deve essere in grado di creare oggetti msDS-GroupManagedServiceAccount. Per saperne di più, consulta Provisioning di Managed Service Account di gruppo.

   Se utilizzi Managed Microsoft AD, il tuo account deve essere membro del gruppo Cloud Service Managed Service Account Administrators. Per maggiori informazioni, vedi Delegare l'amministrazione degli account di servizio gestiti.

3. Digita 15 per uscire dal menu e tornare alla riga di comando (PowerShell).

Installa un runtime del container

Windows Server 2022 richiede un runtime del container, come Docker Community Edition (CE), per creare ed eseguire container Windows. Per ulteriori informazioni sull'installazione di un runtime del container su Windows Server, consulta Guida introduttiva: prepara Windows per i container nella documentazione di Microsoft.

Se hai creato la VM di sviluppo utilizzando l'immagine windows-2019-core-for-containers, puoi saltare la procedura seguente, perché l'immagine ha già Docker installato.

1. Installa 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
   

   Se durante il processo di installazione la connessione al desktop remoto si chiude, riconnettiti alla VM.

2. Attendi il completamento del processo di installazione, quindi digita exit per chiudere la nuova finestra di PowerShell.

3. Digita 15 per uscire dal menu e passare alla riga di comando (PowerShell).

Crea una chiave radice KDS

Prima di creare un gMSA, devi assicurarti che il controller di dominio Active Directory disponga di una chiave radice Key Distribution Services (KDS). Active Directory utilizza la chiave radice KDS per generare le password per gli account di servizio gestiti da Google.

Se utilizzi Managed Microsoft AD, puoi saltare la seguente procedura perché Managed Microsoft AD crea la chiave radice KDS quando crei il dominio.

1. Su gmsa-dev-vm, controlla se Active Directory ha già la chiave radice KDS:

   Get-KdsRootKey
   

   Questo comando mostra l'ID chiave, se esistente.

2. Se non ricevi un ID chiave in risposta, crea la chiave:

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

Crea il gMSA

Quando crei un gMSA, devi fornire i nomi dei computer che hanno accesso al gMSA. Come best practice di sicurezza, devi concedere l'autorizzazione per il gMSA solo alle istanze in cui viene eseguita l'applicazione. Quando crei un pool di nodi Windows Server aggiunto al dominio, viene creato un nuovo gruppo Active Directory per i computer del pool di nodi. Il nome del gruppo corrisponde al nome del gruppo di istanze gestite (MIG) che GKE crea per ipool di nodiol.

1. In PowerShell, imposta le variabili per l'ID progetto Google Cloud , il nome del cluster, il nome pool di nodi Windows, il nome gMSA e il nome di dominio AD:

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

   Sostituisci PROJECT-ID con l'ID progetto Google Cloud .

2. Imposta la configurazione del cluster per lo strumento gcloud:

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

   Sostituisci ZONE-NAME con la zona in cui hai eseguito il deployment del cluster GKE.

3. Recupera il nome di dominio del gruppo Active Directory creato per il pool di nodi:

   $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 l'account gMSA:

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

5. Verifica che l'account di servizio gestito sia stato creato:

   Get-ADServiceAccount -Identity $GmsaName
   

   Se la gMSA è stata creata, l'output è simile al seguente:

   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 :
   

Aggiungi gMSA a GKE

Per utilizzare un gMSA in un cluster Kubernetes, devi creare una risorsa gMSA in Kubernetes e configurare quali spazi dei nomi e account sono autorizzati a utilizzarla.

1. Su gmsa-dev-vm, in PowerShell, installa lo strumento git:

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

2. Installa lo strumento 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. Installa il programma binario gke-gcloud-auth-plugin:

   gcloud components install gke-gcloud-auth-plugin
   

   Attendi qualche minuto per il completamento del processo di installazione.

4. Inizializza lo strumento kubectl con le credenziali del cluster GKE:

   gcloud container clusters get-credentials $GkeClusterName
   

5. Crea il file di specifiche delle credenziali 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
   

   Il nome della risorsa GMSACredentialSpec in Kubernetes deve utilizzare caratteri minuscoli.

   Lo script modifica la capitalizzazione della variabile $GmsaName per rispettare questa limitazione.

   Lo script mostra un messaggio di avviso che indica che il test dell'account di servizio gestito non è riuscito, come previsto. La VM di sviluppo non fa parte del gruppo assegnato al gMSA, pertanto non puoi testare il gMSA dalla VM. Il messaggio di avviso non impedisce al comando di generare la specifica delle credenziali gMSA.

6. Aggiungi la specifica delle credenziali gMSA al cluster GKE:

   kubectl apply -f $CredSpecFile
   

7. Clona il repository GitHub:

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

8. Aggiungi gli oggetti RBAC gMSA al cluster:

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

   gmsa-rbac-webapp-01.yaml crea un oggetto RBAC ClusterRole per gMSA e poi associa il nuovo ruolo del cluster al account di servizio predefinito nello spazio dei nomi default. Se esegui il deployment della tua applicazione in uno spazio dei nomi diverso, modifica il file gmsa-rbac-webapp-01.yaml e cambia lo spazio dei nomi per l'associazione dei ruoli e per il account di servizio.

Deployment e utilizzo dell'applicazione web

Successivamente, creerai l'applicazione web e l'immagine container, eseguirai il deployment della nuova immagine container nel cluster GKE e aprirai l'applicazione web nel browser per verificare che possa utilizzare il gMSA.

Crea ed esegui il deployment dell'applicazione web ASP.NET

1. Su gmsa-dev-vm, in PowerShell, imposta le variabili per la posizione del registro di sistema, il nome del registro di sistema e il tag dell'immagine:

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

   Sostituisci LOCATION con la località in cui hai creato il repository Artifact Registry.

2. Crea l'immagine container:

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

   Per creare immagini container per Windows Server 2019, imposta il valore del parametro -f su Dockerfile-WINDOWS_LTSC2019.

3. Esegui il push dell'immagine container in Artifact Registry:

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

4. Scarica il file YAML dell'applicazione e aggiornalo con la configurazione 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
   

   Se crei nodi Windows Server 2019 in GKE, modifica il file YAML dell'applicazione e cambia il valore di cloud.google.com/gke-windows-os-version da 2022 a 2019.

5. Esegui il deployment dell'applicazione web nel cluster GKE:

   kubectl apply -f $ApplicationYaml
   

Verifica che l'applicazione web ASP.NET sia in esecuzione

L'applicazione web è esposta a internet utilizzando un servizio LoadBalancer. Prima di poter accedere all'applicazione web, devi attendere il deployment del pod e del servizio. Il deployment del pod può richiedere diversi minuti perché le immagini container di Windows Server Core sono di grandi dimensioni (l'immagine dell'applicazione web è superiore a 7 GB) e il nodo impiega un po' di tempo per scaricare l'immagine e creare il container.

1. Controlla lo stato del pod:

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

   Ripeti il comando finché l'output non mostra che lo stato del pod è Running:

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

   Se lo stato del pod rimane In attesa e non cambia in Creazione container o In esecuzione, controlla l'immagine di origine del nodo Windows per assicurarti che sia Windows Server 2022. Puoi anche consultare la tabella di mapping delle versioni per vedere come le versioni di GKE vengono mappate alle versioni di Windows Server. Se le versioni non corrispondono, duplica il file Dockerfile-WINDOWS_LTSC2022, imposta l'immagine container di base nel nuovo file in modo che corrisponda alla versione di Windows Server dei tuoi nodi, quindi ripeti i passaggi per creare ed eseguire il deployment dell'applicazione web ASP.NET.

2. Controlla lo stato del servizio:

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

   Ripeti il comando finché l'output non mostra che il servizio ha un indirizzo IP esterno:

   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. Prendi nota del valore external-ip nell'output, ti servirà in seguito.

Esegui test preliminari nell'applicazione web ASP.NET

Il pod è ora in esecuzione ed è accessibile da internet tramite un bilanciatore del carico di rete. Successivamente, esegui test preliminari per verificare che il container sia stato deployato correttamente e che disponga delle autorizzazioni per utilizzare la gMSA.

1. In un browser, vai a http://EXTERNAL-IP per visualizzare l'applicazione web di test gMSA.

   Sostituisci EXTERNAL-IP con l'indirizzo IP che hai ottenuto nella procedura precedente.

2. Scorri fino alla sezione Controlli preflight e poi fai clic sul pulsante Esegui controlli preflight per verificare che tutti i test siano stati superati.

   Se i test vengono superati, l'output è il seguente:

   [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. Scorri fino alla sezione Informazioni sul contenitore e poi fai clic sul pulsante Esegui script. Verifica che vengano visualizzate informazioni sul contenitore e sul nodo e che non venga visualizzato alcun errore.

Utilizza il gMSA nei container Windows

Ora puoi verificare che la configurazione di gMSA funzioni correttamente eseguendo diversi test nell'applicazione web. Ciascuno dei test utilizza l'account di servizio gestito da Google per uno scopo diverso. Se tutti i test hanno esito positivo, hai configurato correttamente l'account del servizio gestito dal gruppo.

Convalida la configurazione del contenitore gMSA

• Scorri fino alla sezione Connettività del dominio, digita il nome del tuo gMSA (WebApp-01) nella casella Nome account e poi fai clic su Esegui script. Attendi qualche secondo per il completamento dei test.

  L'output è simile al seguente:

  *****   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      *****
  

  Lo script utilizza due cmdlet PowerShell per testare l'accesso all'account di servizio gestito da gruppo:

  • Get-ADServiceAccount: questo cmdlet recupera le informazioni su un gMSA. Se questo cmdlet viene eseguito correttamente, il container è in esecuzione con un gMSA valido.
  • Test-ADServiceAccount: Questo cmdlet verifica se è possibile recuperare le credenziali gMSA. Se il comando cmdlt viene eseguito correttamente, il contenitore viene eseguito in un nodo Windows Server a cui è consentito accedere alle credenziali gMSA.

Esegui l'accesso degli utenti con l'autenticazione di Windows

1. Nella barra di navigazione in alto della pagina, fai clic su Accedi.
2. Quando ti viene chiesto di inserire le credenziali, inserisci il nome utente e la password del dominio.

3. Se visualizzi la pagina Sicuro con i dati del tuo account e non ti vengono richieste le credenziali, il browser ha eseguito automaticamente l'accesso utilizzando la tua identità attuale.

   Una volta autenticato, viene visualizzata la pagina Sicuro. Assicurati di visualizzare le seguenti tre sezioni:

   • Informazioni utente: mostra il tuo nome utente e il tipo di autenticazione utilizzato.
   • Gruppi: mostra l'elenco dei gruppi di cui fai parte. I nomi dei gruppi nell'elenco vengono recuperati da Active Directory.
   • User Claims (Claim utente): mostra l'elenco dei claim per l'utente forniti da Active Directory durante l'accesso. Le rivendicazioni di appartenenza al gruppo mostrano l'SID del gruppo Active Directory, non i nomi.

Oltre a supportare l'autenticazione integrata di Windows, l'applicazione web ASP.NET può utilizzare il proprio gMSA per l'autenticazione quando chiama i server remoti. Utilizzando l'account gMSA, l'applicazione web e qualsiasi altra applicazione in esecuzione nel container Windows possono accedere alle risorse nella rete che richiedono l'autenticazione Windows, come le istanze SQL Server e le condivisioni di rete basate su SMB.

Risoluzione dei problemi

Se riscontri messaggi di errore durante la procedura di configurazione o durante il test dell'applicazione web, consulta le seguenti pagine per la risoluzione dei problemi:

• Risoluzione dei problemi di Windows Server su GKE
• Documentazione di Kubernetes sulla risoluzione dei problemi dei contenitori del server Windows
• Documentazione di Microsoft sulla risoluzione dei problemi relativi ai gMSA per i container Windows

Considerazioni aggiuntive per le applicazioni di produzione

Le istruzioni che hai seguito sono state scritte per fornire un percorso ottimale ai fini del tutorial. Per un ambiente di produzione, potresti apportare modifiche ad alcune procedure per rendere il risultato più solido, come descritto nelle sezioni seguenti.

Considerazioni sui pool di nodi Windows Server

Se prevedi di eseguire il deployment della tua applicazione che utilizza un gMSA e l'applicazione supporta le sessioni client, ti consigliamo di creare almeno due nodi nel pool di nodi. La presenza di più nodi consente di utilizzare l'archiviazione delle sessioni out-of-process per verificare che l'applicazione possa gestire correttamente le sessioni distribuite.

In questo tutorial, creerai un singolo pool di nodi Windows Server per ospitare le tue applicazioni. Tuttavia, potrebbero verificarsi situazioni in cui vuoi creare più node pool Windows Server nel cluster, ad esempio un pool di nodi con dischi permanenti HDD e un altro con dischi permanenti SSD. Se devi eseguire il deployment dell'applicazione in più pool di nodi, fornisci un array di oggetti gruppo Active Directory al parametro PrincipalsAllowedToRetrieveManagedPassword quando crei la gMSA utilizzando il cmdlet New-ADServiceAccount.

Considerazioni su gMSA e nome entità servizio (SPN)

Se la tua applicazione richiede l'autenticazione degli utenti tramite Kerberos (ad esempio per supportare la delega dell'identità), devi accedere all'applicazione utilizzando un DNS personalizzato e configurare gMSA con un nome entità servizio (SPN). Ad esempio, se il bilanciatore del carico espone l'applicazione su GKE tramite https://my-web-app/, devi creare un SPN denominato HTTP/my-web-app in uno dei seguenti modi:

• Per una nuova gMSA, crea la gMSA con gli SPN richiesti. Ad esempio:

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

• Per un gMSA esistente, chiama Set-ADServiceAccount per aggiungere gli SPN richiesti al gMSA. Ad esempio:

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

A seconda della configurazione DNS, potresti anche dover creare un SPN per HTTP/www.my-web-app e HTTP/www.my-web-app.$AdDomain.

Per i protocolli non HTTP, ad esempio un servizio WCF configurato con binding TCP e autenticazione Windows, potrebbe essere necessario creare altri tipi di SPN, ad esempio uno SPN HOST/.

Scelta dell'identità del pool di applicazioni IIS

Le applicazioni web ASP.NET vengono eseguite in Windows sul server web IIS. In IIS, configuri gruppi di applicazioni web che condividono lo stesso processo. Questo gruppo è chiamato pool di applicazioni. Ogni pool di applicazioni è ospitato in un processo dedicato denominato w3wp. I pool di applicazioni IIS forniscono la configurazione del processo, ad esempio se il processo è a 32 bit o 64 bit, e l'identità del processo. Quando esegui un'applicazione web in un container Windows, imposti l'identità del processo del pool di applicazioni in modo che utilizzi l'account Network Service integrato.

Gli account dell'identità del pool di applicazioni locali, supportati anche da IIS, non sono necessari nei container Windows. Gli account dell'identità del pool di applicazioni sono stati creati da IIS per applicare un confine di sicurezza locale quando vengono eseguite più applicazioni web sulla stessa istanza IIS. Con i container Windows, in cui ogni applicazione web è ospitata in un container separato, non è necessario creare un confine di sicurezza all'interno del container, perché il container stesso fornisce il confine di sicurezza.

Anche se l'identità del pool di applicazioni è configurata per utilizzare il service account di rete, se l'applicazione effettua una richiesta a una risorsa esterna che richiede l'autenticazione, l'applicazione si autentica utilizzando la gMSA che hai configurato per il container Windows.

Nota: puoi comunque configurare i pool di applicazioni in IIS per utilizzare gli account identità del pool di applicazioni, ad esempio se vuoi ospitare più applicazioni web nello stesso container e hai bisogno di un limite di sicurezza locale. Come indicato, quando un'applicazione web esegue l'autenticazione per risorse di rete esterne, utilizza gMSA indipendentemente dal fatto che l'identità sia impostata su un account di identità del pool di applicazioni o sull'account NetworkService.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per, le attività descritte in questo documento, eliminerai anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella console Google Cloud , vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Chiudi per eliminare il progetto.

Rimozione di singole risorse

Se vuoi conservare il progetto Google Cloud , ma non vuoi eliminare le risorseGoogle Cloud che hai creato per questo tutorial, puoi rimuovere le risorse singolarmente.

Ripristinare le modifiche di Active Directory

1. Connettiti alla VM di sviluppo e accedi come utente con accesso amministrativo al tuo dominio Active Directory.

2. Nella VM gmsa-dev-vm, se PowerShell non è già aperto, aprilo:

   PowerShell
   

3. Elimina l'account gMSA:

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

Elimina le risorse cloud

1. Nella console Google Cloud , attiva Cloud Shell.

   Attiva Cloud Shell

2. Inizializza l'ambiente gcloud:

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

   Sostituisci quanto segue:

   • PROJECT-ID: l'ID progetto Google Cloud .
   • ZONE-NAME: la zona in cui hai eseguito il deployment del cluster GKE e della VM di sviluppo.
   • LOCATION: la regione in cui hai eseguito il deployment del repository Artifact Registry.

3. Elimina la VM di sviluppo:

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

4. Elimina il account di servizio:

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

5. Elimina il cluster GKE:

   gcloud container clusters delete cluster-1 --quiet
   

6. Se hai creato una regola firewall per i controller Active Directory, eliminala:

   gcloud compute firewall-rules delete allow-gke-pods-to-ad --quiet
   

7. Elimina il repository Docker di Artifact Registry:

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

Per completare, segui i passaggi di pulizia descritti in Configura Active Directory per consentire alle VM di unirsi automaticamente a un dominio.

Passaggi successivi

• Scopri di più sui container Windows Server su GKE.
• Scopri di più sulla creazione di un cluster GKE utilizzando i node pool Windows Server.
• Scopri altri modi per eseguire il deployment delle applicazioni Windows Server.
• Consulta le nostre best practice per il deployment di una foresta di risorse Active Directory su Google Cloud.