Deployment di app ASP.NET con autenticazione di Windows in container GKE Windows

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

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

Obiettivi

  • Creare un cluster GKE con nodi di Windows Server aggiunti al dominio e configurare il cluster per supportare gli Active Directory in Active Directory.
  • Crea ed esegui il deployment di un'immagine container dell'applicazione web ASP.NET che utilizza IIS con autenticazione integrata di Windows.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono beneficiare di una prova gratuita.

Prima di iniziare

  1. Segui i passaggi nel tutorial su come configurare Active Directory per le VM in modo che entrino automaticamente a un dominio per creare il servizio Cloud Run per aggiungere il dominio Active Directory.

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

    Quando completi l'altro tutorial, disponi di un nuovo servizio Cloud Run e il relativo URL viene stampato nella finestra di PowerShell (il valore della variabile $RegisterUrl). Prendi nota dell'indirizzo del servizio, perché lo utilizzi in questo tutorial.

  3. Assicurati di aver abilitato le API per Compute Engine, Google Kubernetes Engine, Cloud Build, Container Registry e l'API Resource Manager:

    Abilita le API

    Una volta completato questo tutorial, puoi evitare di continuare la fatturazione eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Introduzione

Le applicazioni basate su Windows che vengono eseguite in un server Windows che fanno parte del dominio spesso utilizzano le identità Microsoft Active Directory (AD) per autenticare gli utenti e le applicazioni. Di seguito sono riportati alcuni casi d'uso comuni:

  • Creazione di applicazioni web ASP.NET che utilizzano l'autenticazione integrata di Windows per autenticare gli utenti di Active Directory mentre tentano di accedere all'applicazione web.
  • Creazione di applicazioni che utilizzano l'account del 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 aggiunti a un dominio, quindi 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 quindi non possono accedere alle risorse protette nella rete. Per ulteriori informazioni su come ASP.NET accede alle risorse protette, consulta la sezione delle identità dei pool di applicazioni nella documentazione di Microsoft.

Invece di utilizzare un account computer, i container Windows possono utilizzare un'account di servizio gestito (GMSA) del gruppo Active Directory per accedere ad Active Directory e ad altre risorse protette nella rete, come condivisioni di file e istanze SQL Server. Per ulteriori informazioni, consulta la panoramica degli account di servizio gestiti del gruppo nella documentazione di Microsoft.

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

Contenitori di Windows Server con dominio aggiunto al dominio attivo su GKE.

Il diagramma mostra i seguenti elementi:

  • VM di sviluppo. In questo tutorial, creerai una VM Windows che utilizzerai per creare l'immagine del container dell'applicazione web ASP.NET e per creare la gMSA.
  • Cluster e nodi GKE. Il cluster GKE in questo tutorial ha sia un pool di nodi Linux sia un pool di nodi Windows Server utilizzati nei seguenti modi:
    • I nodi Linux eseguono componenti di sistema che vengono eseguiti solo sui sistemi operativi Linux, ad esempio il server delle metriche GKE.
    • I nodi Windows Server vengono utilizzati per l'hosting dei container Windows Server e fanno parte di un dominio Active Directory.
  • Infrastruttura di Active Directory. Per ottenere i nodi GKE di Windows per l'aggiunta a un dominio, devi prima eseguire il tutorial Configurazione di Active Directory per VM per l'unione automatica dei domini. Nel tutorial imparerai a creare un servizio Cloud Run responsabile della registrazione di nuovi computer (istanze) in Active Directory e di fornire a ogni nuova istanza una password temporanea che l'istanza utilizza per completare il processo di aggiunta del dominio. Ogni nuova istanza nel pool di nodi Windows Server chiama il servizio Cloud Run per l'unione al dominio Active Directory.
  • Bilanciatore del carico di rete. Quando un utente on-premise apre il browser e passa all'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 GKE LoadBalancer per la tua applicazione web. L'utente si autentica anche all'applicazione web passando le proprie credenziali Active Directory all'applicazione web.

Creazione dell'infrastruttura

Dopo aver completato il tutorial correlato, puoi creare i componenti dell'infrastruttura per il tutorial attuale, che include quanto segue:

  • Una VM di 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 l'inserimento delle risorse gMSA nei deployment.

Crea una VM di sviluppo

L'immagine container di Windows Server che crei deve corrispondere alla versione Windows Server della VM in cui crei l'immagine container. Questa versione deve corrispondere anche alla versione di Windows Server dei nodi del server GKE. La creazione di un'immagine container o l'esecuzione di un container in una versione diversa di Windows Server generano un errore. Per ulteriori informazioni sui requisiti di compatibilità dei contenitori di Windows, consulta Abbinare la versione host del container alle versioni dell'immagine container.

Questo tutorial utilizza la versione 2019 del Long-Term Servicing Channel (LTSC) di Windows Server per la VM, i nodi Windows Server in GKE e l'immagine container. Per ulteriori informazioni, consulta la sezione Mappatura delle versioni tra le versioni di Windows Server e GKE.

  1. Nella console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console, 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à installato 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 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 e l'area geografica del progetto Google Cloud per l'ambiente attuale:

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

    Sostituisci quanto segue:

    • PROJECT-ID: il tuo 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 area geografica in cui hai eseguito il deployment del servizio Cloud Run per il 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 all'account di servizio l'accesso a Container Registry:

    gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
        --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
        --role="roles/storage.admin"
    
    gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin \
        gs://artifacts.$GOOGLE_CLOUD_PROJECT.appspot.com
    
  7. Concedi all'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"
    

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

  8. Crea una nuova VM di Windows Server:

    gcloud compute instances create gmsa-dev-vm \
        --image-project windows-cloud \
        --image-family windows-2019-core-for-containers \
        --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"
    

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

    La VM viene creata con un indirizzo IP esterno per consentire la comunicazione con Internet. Devi avere una VM di accesso a Internet in modo che possa scaricare diverse utilità, ad esempio git e kubectl, e scaricare l'applicazione web ASP.NET da GitHub.

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

Crea il 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
    

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

Creare un pool di nodi Windows Server in GKE

Quando crei un nuovo cluster GKE mediante l'interfaccia a riga di comando, il cluster viene creato con un pool di nodi Linux. Per utilizzare Windows Server su GKE, devi creare un pool di nodi Windows Server.

Per eseguire i container interni al cluster, il cluster GKE deve disporre di almeno un nodo Linux. Impossibile creare un cluster GKE con solo 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 \
        --num-nodes 2 \
        --no-enable-autoupgrade \
        --metadata sysprep-specialize-script-ps1="iex((New-Object System.Net.WebClient).DownloadString('$AD_JOIN_SERVICE_URL'))"
    

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

    Il cmdlet iex scarica lo script di PowerShell dal servizio di aggiunta del dominio Active Directory eseguito per il deployment in Cloud Run. Quindi, esegue lo script che aggiunge la nuova istanza al dominio Active Directory.

    Il parametro --no-enable-autoupgrade disabilita l'upgrade automatico dei nodi per tutti i nodi nel pool. È necessario perché l'upgrade di un'immagine Windows di un nodo può causare incompatibilità tra la versione di Windows Server del nodo e la versione di Windows Server del pod. Per ulteriori informazioni, consulta L'upgrade dei pool di nodi Windows Server.

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

  3. Attendi alcuni minuti fino alla creazione del pool di nodi, quindi esegui il comando seguente per verificare che tutti i nodi si siano aggiunti 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.

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

Puoi applicare la regola in base a un account di servizio che hai assegnato ai controller di dominio o puoi applicarla utilizzando un tag di rete come illustrato in questo tutorial. Per saperne di più sulle porte correlate ad Active Directory, consulta la documentazione sui requisiti di protocollo e porte di Active Directory e sull'utilizzo di Active Directory tra firewall.

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

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

    CLUSTER_IP_RANGE=`gcloud container clusters describe cluster-1 --format="value(clusterIpv4Cidr)"`
    
  2. Crea una regola firewall per concedere l'accesso ai pod GKE 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 che viene assegnato ai VM o ai controller di dominio.

Configurare GKE per supportare l'utilizzo di gMSA

Per utilizzare un oggetto gMSA nei nodi Windows Server, devi creare l'oggetto gMSA in Active Directory, creare una risorsa gMSA corrispondente in GKE e abilitare i pod appena creati per recuperare le loro credenziali gMSA.

  1. In Cloud Shell, scarica ed esegui lo script webhook di gMSA:

    export K8S_GMSA_DEPLOY_DOWNLOAD_REV=cf59263c21f6af7d4a9a0128822516a199395cc6
    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 --overwrite
    rm -drf gmsa-webhook-certs
    

    Lo script aggiunge il manifest della definizione delle risorse personalizzate gMSA (CRD) al tuo cluster GKE ed esegue il deployment di un webhook che fornisce le specifiche gMSA ai pod. Ora puoi archiviare le specifiche gMSA nel cluster e configurare gli oggetti gMSA per pod e container.

    Per saperne di più su Kubernetes e gMSA, vedi Configurare GMSA per pod e container Windows.

Il cluster GKE è ora pronto per eseguire applicazioni Windows che richiedono l'utilizzo di un gMSA. Ad esempio, puoi eseguire un'applicazione web ASP.NET nei nodi Windows Server. Puoi configurare l'applicazione in modo che acceda agli utenti con l'autenticazione Windows o che utilizzi l'estensione GMSA di Pod Podcast per accedere a una condivisione di rete remota o a un database SQL Server.

Integrazione con Active Directory

Quindi creerai un gMSA per la tua applicazione web ASP.NET in Active Directory, configurerai il modo in cui può essere utilizzato e da chi e quindi aggiungerai 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 ulteriori informazioni, consulta Provisioning degli account di servizio gestiti.

    Se utilizzi la gestione gestita di Microsoft AD, il tuo account deve essere membro del gruppo Cloud Service Managed Service Account Administrators. Per ulteriori informazioni, consulta la sezione Creazione di un account di servizio gestito del gruppo.

  3. Apri PowerShell:

    PowerShell
    

Crea una chiave root KDS

Prima di creare un gMSA, devi assicurarti che il controller di dominio Active Directory disponga di una chiave root KDS (Key Distribution Services). Active Directory utilizza la chiave root KDS per generare le password per gli oggetti gMSA.

Se utilizzi Microsoft Active Directory gestito, puoi saltare la seguente procedura perché crea una chiave root KDS quando crei il dominio.

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

    Get-KdsRootKey
    

    Questo comando visualizza 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 gMSA

Quando crei un servizio gMSA, devi fornire i nomi dei computer che hanno accesso al gMSA. Come best practice per la sicurezza, concedi l'autorizzazione a 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 il pool di nodi.

  1. In PowerShell, imposta le variabili per l'ID progetto Google Cloud, il nome del cluster, il nome del pool di nodi Windows, il nome gMSA e il nome del 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 di Google Cloud.

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

    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 il gMSA:

    New-ADServiceAccount -Name $GmsaName `
    -DNSHostName "$GmsaName.$AdDomain" `
    -PrincipalsAllowedToRetrieveManagedPassword $GroupDN
    
  5. Verifica che il gMSA sia stato creato:

    Get-ADServiceAccount -Identity $GmsaName
    

    Se è stato creato gMSA, 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 :
    

Aggiungere gMSA a GKE

Per utilizzare un gMSA in un cluster Kubernetes, devi creare una risorsa gMSA in Kubernetes e configurare gli spazi dei nomi e gli account che possono utilizzarlo.

  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. Inizializza lo strumento kubectl con le credenziali del tuo cluster GKE:

    gcloud container clusters get-credentials $GkeClusterName
    
  4. Crea il file della specifica 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/v1alpha1";
    "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 cambia le lettere maiuscole della variabile $GmsaName in modo da rispettare questa limitazione.

    Lo script mostra un messaggio di avviso indicante che il test dell'account di servizio gestito non è riuscito, previsto. La tua VM di sviluppo non è un membro del gruppo assegnato a gMSA e quindi non puoi testare gMSA dalla VM. Il messaggio di avviso non impedisce al comando di generare la specifica delle credenziali gMSA.

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

    kubectl apply -f $CredSpecFile
    
  6. Clona il repository GitHub:

    git clone https://github.com/GoogleCloudPlatform/gke-aspnet-gmsa.git
    cd gke-aspnet-gmsa
    
  7. Aggiungi gli oggetti RBAC gMSA al tuo cluster:

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

Deployment e utilizzo dell'applicazione web

In seguito, crei l'applicazione web e l'immagine container, sottoponi a deployment la nuova immagine container nel cluster GKE e apri l'applicazione web nel browser per verificare che l'applicazione web possa utilizzare gMSA.

Creare ed eseguire il deployment dell'applicazione web ASP.NET

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

    $RegistryLocation = "STORAGE-REGION.gcr.io"
    $ProjectsRegistry = "$RegistryLocation/$ProjectId"
    $ImageTag = "$ProjectsRegistry/test-gmsa:latest"
    

    Sostituisci STORAGE-REGION con la posizione in cui vuoi archiviare l'immagine container. I valori supportati sono us, eu o asia. Scegli una località vicina all'area geografica in cui crei la VM di sviluppo e il cluster GKE.

  2. Crea l'immagine container:

    docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC .
    
  3. Esegui il push dell'immagine container a Container Registry:

    gcloud auth configure-docker $RegistryLocation --quiet
    docker push $ImageTag
    
  4. Scarica il file YAML dell'applicazione e aggiornalo con la tua configurazione gMSA:

    $ApplicationYaml = Join-Path $env:TEMP "gmsa-test-webapp-01.yaml"
    
    (Get-Content gmsa-test-webapp-01.yaml.template) `
    -Replace '\${registry_path}',$ProjectsRegistry | `
    Set-Content $ApplicationYaml
    
  5. Esegui il deployment dell'applicazione web nel tuo cluster GKE:

    kubectl apply -f $ApplicationYaml
    

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

L'applicazione web è esposta a Internet tramite un servizio LoadBalancer. Per poter passare 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 è più grande di 7 GB) e richiede un po' di tempo prima che il nodo scarichi l'immagine e crei 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 è In esecuzione:

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

    Se lo stato del pod resta In attesa e non passa a ContainerCreating o Running, controlla l'immagine di origine del nodo Windows per assicurarti che sia Windows Server 2019. Puoi anche controllare la tabella delle mappature delle versioni per vedere in che modo le versioni di GKE vengono mappate alle versioni di Windows Server. Se le versioni non corrispondono, aggiorna il file Dockerfile-WINDOWS_LTSC con l'immagine container di base che corrisponde alla versione di Windows Server dei nodi, quindi ripeti i passaggi per creare e sottoporre a deployment l'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 un indirizzo IP esterno del servizio:

    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. Osserva il valore external-ip nell'output, che ti servirà in un secondo momento.

Eseguire 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 deployment del container sia stato eseguito correttamente e che disponga delle autorizzazioni per utilizzare 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 ricevuto nella procedura precedente.

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

    Se i test hanno esito positivo, 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 Container Information e fai clic sul pulsante Run Script. Verifica che vengano visualizzate le informazioni sul container e sul nodo e che non venga visualizzato alcun errore.

Utilizzare gMSA nei container Windows

Ora puoi verificare che la configurazione gMSA funzioni correttamente eseguendo diversi test nell'applicazione web. Ciascun test utilizza la funzione gMSA per uno scopo diverso. Se tutti i test hanno esito positivo, allora hai configurato correttamente il gMSA.

Convalidare la configurazione del container gMSA

  • Scorri fino alla sezione Connettività dominio, digita il nome di gMSA (WebApp-01) nella casella Nome account, quindi fai clic su Esegui script. Attendi qualche secondo affinché il test sia completato.

    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 di PowerShell per testare l'accesso a gMSA.

    • Get-ADServiceAccount: questo cmdlet recupera le informazioni relative a un gMSA. Se questo cmdlt viene eseguito correttamente, il container è in esecuzione con un gMSA valido.
    • Test-ADServiceAccount: questo cmdlet verifica se è in grado di recuperare le credenziali gMSA. Se il cmdlt viene eseguito correttamente, il container è in esecuzione in un nodo Windows Server autorizzato ad accedere alle credenziali gMSA.

Accedere agli utenti con l'autenticazione di Windows

  1. Nella barra di navigazione in alto della pagina, fai clic su Login (Accedi).
  2. Quando ti viene chiesto di inserire le credenziali, inserisci il nome utente e la password del dominio.
  3. Se vedi la pagina Secure con i dati dell'account e non ti vengono richieste le credenziali, il browser ti ha eseguito automaticamente l'accesso utilizzando la tua identità attuale.

    Dopo l'autenticazione, viene visualizzata la pagina Secure. Assicurati di visualizzare le tre sezioni seguenti:

    • Informazioni utente: mostra il tuo nome utente e il tipo di autenticazione utilizzata.
    • Gruppi: mostra l'elenco di gruppi a cui appartieni. I nomi dei gruppi presenti nell'elenco vengono recuperati da Active Directory.
    • Rivendicazioni utente: mostra l'elenco delle rivendicazioni dell'utente in base a quanto fornito da Active Directory durante l'accesso. Le attestazioni di appartenenza al gruppo mostrano il SID di Active Directory Group, non i nomi.

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

Risolvere i problemi

Se durante la procedura di configurazione o durante il test dell'applicazione web ricevi messaggi di errore, fai riferimento alle seguenti pagine di risoluzione dei problemi:

Ulteriori considerazioni per le applicazioni in produzione

Le istruzioni sono state scritte per fornire un percorso ottimale per le finalità del tutorial. Per un ambiente di produzione, potresti apportare modifiche ad alcune procedure per rendere il risultato più efficace, come descritto nelle sezioni seguenti.

Considerazioni sul pool di nodi Windows Server

Se prevedi di eseguire il deployment di una tua applicazione che utilizza un gMSA e tale applicazione supporta le sessioni client, ti consigliamo di creare almeno due nodi nel pool di nodi. La presenza di più nodi ti consente di utilizzare l'archiviazione fuori sessione per verificare che la tua 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 esserci situazioni in cui vuoi creare più pool di nodi Windows Server nel cluster, ad esempio un pool di nodi con dischi permanenti HDD (PD) e un altro pool di nodi con DP 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 il gMSA utilizzando il cmdlet New-ADServiceAccount.

Considerazioni relative a gMSA e al nome entità servizio (SPN)

Se la tua applicazione richiede l'autenticazione degli utenti mediante Kerberos (ad esempio, per supportare la delega delle identità), devi accedere all'applicazione utilizzando un DNS personalizzato e configura 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 un nuovo GMSA, crea il file 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 del DNS, potresti dover creare anche un SPN per HTTP/www.my-web-app e HTTP/www.my-web-app.$AdDomain.

Per i protocolli non HTTP, come un servizio WCF configurato con binding TCP e autenticazione Windows, potrebbe essere necessario creare altri tipi di SPN, ad esempio un 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, puoi configurare gruppi di applicazioni web che condividono lo stesso processo. Questo gruppo viene chiamato gruppo di applicazioni. Ogni pool di applicazioni è ospitato in un processo dedicato denominato w3wp. I pool di applicazioni IIS forniscono una configurazione di processo, ad esempio se il processo è a 32 o 64 bit e forniscono 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 di identità del pool di applicazioni locali, supportati anche da IIS, non sono obbligatori nei container Windows. Gli account di identità del pool di applicazioni sono stati creati da IIS come mezzo per applicare un limite 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 limite di sicurezza all'interno del container, perché è il container stesso a fornire il limite.

Anche se l'identità del pool di applicazioni è configurata in modo da utilizzare l'account di servizio di rete, se l'applicazione invia una richiesta a una risorsa esterna che richiede l'autenticazione, l'applicazione viene autenticata utilizzando l'oggetto gMSA configurato per il container Windows.

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.

  1. Nella console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

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

Rimozione di singole risorse

Se vuoi mantenere il tuo progetto Google Cloud ma non vuoi eliminare le risorse di Google Cloud che hai creato per questo tutorial, puoi rimuoverle singolarmente.

Annulla modifiche a 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 gMSA:

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

Eliminare le risorse cloud

  1. Nella console, attiva Cloud Shell.

    Attiva Cloud Shell

  2. Inizializza l'ambiente gcloud:

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

    Sostituisci PROJECT-ID con l'ID progetto di Google Cloud e ZONE-NAME con la zona in cui hai eseguito il deployment del cluster GKE e della VM di sviluppo.

  3. Elimina la VM di sviluppo:

    gcloud compute instances delete gmsa-dev-vm --quiet
    
  4. Elimina l'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 l'immagine dell'applicazione web:

    gcloud container images delete STORAGE-REGION.gcr.io/$GOOGLE_CLOUD_PROJECT/test-gmsa --force-delete-tags --quiet
    

    Sostituisci STORAGE-REGION con la località che hai scelto per memorizzare l'immagine container. I valori supportati sono us, eu o asia.

Per completare l'operazione, segui i passaggi per la pulizia descritti in Configurazione di Active Directory per VM per l'aggiunta automatica di un dominio.

Passaggi successivi