Questo tutorial mostra come creare un'applicazione web ASP.NET che utilizza IIS con Autenticazione Windows integrata, e come eseguirne il deployment in un ambiente Google Kubernetes Engine (GKE) utilizzando un container Windows un cluster con nodi Windows Server uniti al dominio. Questa configurazione è utile per il deployment di applicazioni ASP.NET in container Windows su Google Cloud in modo che le applicazioni possano eseguire l'autenticazione in altre risorse Windows. La mostra anche come creare un account di servizio gestito (gMSA) di gruppo Active Directory e come configurare il deployment dell'applicazione web per l'uso da parte di GKE.
Questo tutorial è destinato agli amministratori di sistema. Si presume che tu abbia familiarità con Active Directory e avere esperienza nel lavorare con Google Kubernetes Engine (GKE).
Obiettivi
- Crea un cluster GKE unito a un dominio Nodi Windows Server e configurare il cluster in modo che supporti Active Directory gMSA.
- Crea ed esegui il deployment di un'immagine container di applicazioni web ASP.NET che utilizza IIS con autenticazione integrata di Windows.
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:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Prima di iniziare
Segui i passaggi nella Configurare Active Directory per consentire alle VM di aggiungere automaticamente un dominio tutorial per creare il join con un dominio Active Directory dal servizio Cloud Run.
Se esegui questo tutorial in un progetto Google Cloud diverso da quello in cui hai creato una VM per testare l'unione automatica al dominio, quindi i passaggi per abilitare un progetto per l'aggiunta automatica al dominio nel tuo progetto Google Cloud.
Quando completi l'altro tutorial, avrai a disposizione una nuova Il servizio Cloud Run e il relativo URL vengono stampati in PowerShell (il valore della variabile
$RegisterUrl
). Prendi nota dell'indirizzo perché lo usi in questo tutorial.Assicurati di aver abilitato le API per Compute Engine, GKE, Cloud Build, Artifact Registry e API Cloud Resource Manager:
Una volta completato questo tutorial, puoi evitare la fatturazione continuata le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.
Architettura
Le applicazioni basate su Windows eseguite in un Windows Server aggiunto a un dominio spesso utilizzano Identità Microsoft Active Directory (AD) per autenticare gli utenti e diverse applicazioni. Ecco alcuni casi d'uso comuni:
- Creazione di applicazioni web ASP.NET che utilizzano Autenticazione Windows integrata per autenticare gli utenti di Active Directory quando tentano di accedere applicazione web.
- Creazione di applicazioni che utilizzano il computer Active Directory del server di accesso rapido alle risorse sulla rete, ad esempio una condivisione SMB remota un'istanza Microsoft SQL Server remota.
I container Windows non possono essere uniti a un dominio e, di conseguenza, non hanno computer in Active Directory. Per questo motivo, le applicazioni web ASP.NET che eseguono nei container Windows non possono autenticare gli utenti di Active Directory è stata eseguita l'autenticazione Windows integrata, pertanto non è possibile accedere a risorse protette nella rete. Per ulteriori informazioni su come ASP.NET accede in modo protetto vedi le risorse Identità pool di applicazioni nella documentazione Microsoft.
Anziché utilizzare un account computer, i container Windows possono utilizzare un Identità dell'account di servizio gestito (gMSA) del gruppo di directory per accedere ad Attivo Directory e altre risorse protette nella rete, come condivisioni di file e di SQL Server. Per ulteriori informazioni, vedi Panoramica degli account di servizio gestiti da gruppo nella documentazione Microsoft.
Il seguente diagramma dell'architettura mostra le risorse utilizzate in tutorial:
Il diagramma mostra i seguenti elementi:
- VM di sviluppo. In questo tutorial, creerai una VM Windows Server da utilizzare per creare l'immagine container dell'applicazione web ASP.NET e per durante la creazione del gMSA.
- Cluster e nodi GKE. La
Il cluster GKE in questo tutorial ha sia un nodo Linux
e un pool di nodi Windows Server utilizzati nei modi seguenti:
- I nodi Linux eseguono componenti di sistema che vengono eseguiti solo Sistemi operativi Linux, come il server delle metriche GKE.
- I nodi di Windows Server vengono utilizzati per l'hosting di Windows Server dei container e fanno parte di un dominio Active Directory.
- Infrastruttura Active Directory. Per ottenere GKE I nodi Windows da unire al dominio, devi prima esaminare Configurare Active Directory per consentire alle VM di aggiungere automaticamente un dominio tutorial di Google Cloud. In questo tutorial creerai un servizio Cloud Run responsabile della registrazione di nuovi computer (istanze) in Active Directory, e fornendo a ogni nuova istanza una password temporanea per completare il processo di adesione al dominio. Ogni nuova istanza in Windows Il pool di nodi server chiama il servizio Cloud Run per unirsi alla 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 una il bilanciatore del carico di rete. Il bilanciatore del carico viene creato in GKE quando si crea un cluster GKE Servizio LoadBalancer per la tua applicazione web. L'utente esegue anche l'autenticazione all'applicazione web passando le loro credenziali di Active Directory applicazione web.
Creazione dell'infrastruttura
Dopo aver completato il tutorial correlato, creerai l'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 l'accesso ai pod GKE 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 creata deve corrispondere al Versione server della VM in cui crei l'immagine container. Questa versione deve corrispondono anche alla versione Windows Server della tua finestra GKE Nodi server. Creazione di un'immagine container o esecuzione di un container in di Windows Server restituisce un errore. Per ulteriori informazioni di compatibilità dei container Windows, consulta Corrispondenza della versione host del contenitore con le versioni delle immagini container
Questo tutorial utilizza la versione LTSC (Long-Term Servicing Channel) 2022 di Windows Server per la VM, i nodi Windows Server in GKE, e l'immagine container. Per ulteriori informazioni, vedi mappatura delle versioni tra le versioni di Windows Server e le versioni GKE.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
- Se PowerShell è aperto, chiudilo digitando
exit
. 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 Prima di iniziare .
Imposta la regione e l'ID 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
: l'ID del tuo progetto Google Cloud.ZONE-NAME
: la zona in cui eseguire il deployment di tutte le VM. Per ridurre latenza, ti consigliamo di selezionare una zona nella stessa regione in cui hai eseguito il deployment del servizio Cloud Run aggiunto al dominio Active Directory.
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"
Concedi all'account di servizio accesso in Artifact Registry:
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \ --role="roles/artifactregistry.writer"
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é dispone delle autorizzazioni necessarie per creare cluster GKE in del progetto e di gestire le risorse nei cluster, incluse quelle basate di controllo dell'accesso (RBAC). Le risorse RBAC sono necessarie per controllare quale pod è autorizzato a usare un gMSA.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"
Se prevedi di eseguire il deployment delle applicazioni containerizzate su Windows Server 2019 container, modifica il valore parametro
--image-family
inwindows-2019-core-for-containers
.L'ambito
https://www.googleapis.com/auth/cloud-platform
abilita per accedere a tutte le API Google Cloud, a seconda dei ruoli IAM definite per l'account di servizio dell'istanza.La VM viene creata indirizzo IP esterno per poter comunicare con internet. È necessaria la VM accesso a internet in modo da poter scaricare diverse utilità, git e kubectl, e scaricare l'applicazione web ASP.NET da GitHub.
Durante la fase
sysprep
, la nuova istanza viene unita ad Active Dominio directory per consentirti di accedere in remoto all'istanza utilizzando l'account del tuo dominio. Lo script nel comandosysprep
installa anche Modulo PowerShell per Active Directory.
Crea un repository Docker Artifact Registry
In Cloud Shell, imposta la località predefinita per il nuovo Repository Artifact Registry:
gcloud config set artifacts/location LOCATION
Sostituisci
LOCATION
con un regione in cui vuoi creare il repository Artifact Registry. Per ridurre latenza, ti consigliamo di selezionare la stessa regione in cui hai eseguito il deployment la VM di sviluppo.Crea il repository Docker di Artifact Registry:
gcloud artifacts repositories create windows-container-images \ --repository-format=docker
Crea un cluster GKE
In Cloud Shell, imposta una variabile di ambiente per il nome il cluster GKE:
export GKE_CLUSTER_NAME=cluster-1
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 Parametro
--release-channel
inrapid
esegue il deployment del cluster GKE la versione di Kubernetes. Il parametro--enable-ip-alias
viene attivato 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 l'interfaccia a riga di comando, viene creato con un pool di nodi Linux. Per utilizzare Windows Server GKE, devi creare un pool di nodi Windows Server.
I cluster GKE devono avere almeno un nodo Linux per eseguire container interni (di sistema) del cluster. un cluster GKE solo con nodi Windows Server.
In Cloud Shell, imposta una variabile di ambiente per il nome pool di nodi di Windows Server:
export NODE_POOL_NAME=windows-server-pool
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 su Windows Server 2019 dei container, cambia il parametro
--windows-os-version
inltsc2019
.La chiave dei metadati
sysprep-specialize-script-ps1
è un chiave integrata che punta a uno script PowerShell che viene eseguito durante GCESysprep prima del primo avvio dell'istanza.La
iex
Il cmdlet scarica lo script PowerShell da Active Directory servizio di join al dominio di cui hai eseguito il deployment in Cloud Run. Poi esegue lo script che unisce la nuova istanza al dominio Active Directory.Il parametro
--no-enable-autoupgrade
viene disattivato upgrade automatico dei nodi per tutti i nodi nel pool. Questo perché l'upgrade delle risorse Windows l'immagine può causare incompatibilità tra la versione di Windows Server del nodo e la versione di Windows Server del pod. Per ulteriori informazioni, vedi Upgrade dei pool di nodi Windows Server.Dopo la creazione di ciascun nodo, lo script PowerShell
domain-join
si unisce il nodo al dominio.Attendi alcuni minuti fino alla creazione del pool di nodi, quindi esegui questo comando per verificare che tutti i nodi siano parte del 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 Comandogrep
.
Concedere ai pod GKE l'accesso ad Active Directory
Devi creare una regola firewall che permetta l'accesso a GKE del cluster per accedere ai controller di dominio utilizzando quanto segue 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 controller di dominio oppure applicarlo utilizzando un tag di rete così com'è in questo tutorial. Per ulteriori informazioni sulle porte correlate ad Active Directory, consulta documentazione su Requisiti di protocollo e porta di Active Directory e utilizzando Active Directory sui firewall.
Se utilizzi Servizio gestito per Microsoft Active Directory (Microsoft AD gestito), puoi saltare questa procedura.
In Cloud Shell, recupera il pod del cluster GKE Intervallo di indirizzi IP:
CLUSTER_IP_RANGE=`gcloud container clusters describe $GKE_CLUSTER_NAME --format="value(clusterIpv4Cidr)"`
crea una regola firewall per concedere l'accesso ai pod GKE in 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 al tuo controller di dominio delle VM in esecuzione.
Configura GKE per supportare l'utilizzo di gMSA
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.
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 gMSA definizione di risorsa personalizzata (CRD) al tuo cluster GKE ed esegue il deployment webhook che fornisce le specifiche gMSA ai pod. Ora puoi archiviare specifiche gMSA nel cluster e configurare gMSA per pod containerizzati.
Per saperne di più su Kubernetes e gMSA, consulta Configurare GMSA per pod e container Windows.
Il tuo cluster GKE è ora pronto per eseguire le applicazioni Windows che richiedono l'utilizzo di un gMSA. Ad esempio, puoi eseguire un'istanza web ASP.NET nei nodi di Windows Server. Puoi configurare l'applicazione consentire agli utenti di eseguire l'pod con l'autenticazione Windows o fare in modo che l'applicazione utilizzi gMSA per accedere a una condivisione di rete remota o a un database SQL Server.
Integrazione con Active Directory
Quindi, creerai un gMSA per l'applicazione web ASP.NET in Active Directory, configurare come può essere utilizzato e da chi, quindi aggiungere la sua configurazione con GKE.
Accedi e avvia PowerShell
- Connetti a
la VM
gmsa-dev-vm
. Accedi a Windows utilizzando un account Active Directory a cui è consentito creare un gMSA.
Il tuo account deve essere membro del gruppo
Domain Admins
o deve essere in grado di crearemsDS-GroupManagedServiceAccount
oggetti. Per ulteriori informazioni le informazioni, vedi Provisioning degli account di servizio gestiti di gruppo.Se utilizzi Microsoft Active Directory gestito, il tuo account deve essere membro del gruppo
Cloud Service Managed Service Account Administrators
. Per ulteriori informazioni, vedi Delegare l'amministrazione degli account di servizio gestiti.Digita
15
per uscire dal menu e passare alla riga di comando (PowerShell).
Installa un runtime container
Windows Server 2022 richiede un runtime dei container, ad esempio Docker Community Versione (CE) per creare ed eseguire container Windows. Per ulteriori informazioni installare un runtime container su Windows Server, consulta Per iniziare: prepara le finestre per i container nella documentazione Microsoft.
Se hai creato la VM di sviluppo utilizzando windows-2019-core-for-containers
puoi saltare la procedura seguente perché l'immagine ha già
Docker installato.
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 di Remote Desktop si chiude, riconnettiti alla VM.
Attendi il completamento del processo di installazione, quindi digita
exit
per chiudere nuova finestra di PowerShell.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 dominio Active Directory ha un Chiave principale KDS (Key Distribution Services). Active Directory utilizza la chiave radice KDS per generare password per gMSA.
Se utilizzi Microsoft Active Directory gestito, puoi saltare la procedura seguente poiché Microsoft Active Directory gestito crea la chiave radice KDS quando crei dominio.
Su
gmsa-dev-vm
, controlla se Active Directory dispone già della chiave principale KDS:Get-KdsRootKey
Questo comando visualizza l'ID della chiave, se esistente.
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 abbiano accesso al gMSA. Come best practice per la sicurezza, dovresti concedere l'autorizzazione per il gMSA solo per le istanze in cui è in esecuzione l'applicazione. Quando crei un pool di nodi Windows Server aggiunto al dominio, un nuovo viene creato per i computer del pool di nodi. Il nome del gruppo corrisponde il nome del gruppo di istanze gestite che GKE per il pool di nodi.
In PowerShell, imposta le variabili per l'ID progetto Google Cloud, il cluster nome del pool di nodi, il nome del 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 del tuo progetto Google Cloud.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 cluster GKE.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
Crea il gMSA:
New-ADServiceAccount -Name $GmsaName ` -DNSHostName "$GmsaName.$AdDomain" ` -PrincipalsAllowedToRetrieveManagedPassword $GroupDN
Verifica che il gMSA sia stato creato:
Get-ADServiceAccount -Identity $GmsaName
Se è stato creato il 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 :
Aggiungi gMSA a GKE
Per utilizzare un gMSA in un cluster Kubernetes, devi creare una risorsa gMSA in e configurare gli spazi dei nomi e gli account autorizzati a utilizzare Kubernetes li annotino.
Su
gmsa-dev-vm
, in PowerShell, installa lo strumentogit
:Install-Script -Name Install-Git -Force Install-Git.ps1 $env:Path += ";c:\program files\git\bin"
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"
Installa il programma binario
gke-gcloud-auth-plugin
:gcloud components install gke-gcloud-auth-plugin
Attendi alcuni minuti per il completamento del processo di installazione.
Inizializza lo strumento
kubectl
con il tuo GKE credenziali del cluster:gcloud container clusters get-credentials $GkeClusterName
Crea il Specifiche delle credenziali gMSA file:
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 l'uso delle maiuscole della variabile
$GmsaName
per renderlo conforme con questa restrizione.Lo script visualizza un messaggio di avviso che indica che il test del servizio gestito Errore dell'account, come previsto. La tua VM di sviluppo non è membro di il gruppo assegnato al gMSA, quindi non puoi testare gMSA dalla VM. Il messaggio di avviso non interrompe il comando generando la specifica delle credenziali gMSA.
Aggiungi la specifica delle credenziali gMSA a GKE cluster:
kubectl apply -f $CredSpecFile
Clona il repository GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples cd kubernetes-engine-samples/windows/aspnet-gmsa/
Aggiungi gli oggetti RBAC gMSA al cluster:
kubectl apply -f gmsa-rbac-webapp-01.yaml
gmsa-rbac-webapp-01.yaml
crea un oggetto RBACClusterRole
per gMSA e quindi associa il nuovo ruolo del cluster all'account di servizio predefinito in lo spazio dei nomidefault
. Se esegui il deployment della tua applicazione in un uno spazio dei nomi diverso, modifica il filegmsa-rbac-webapp-01.yaml
per l'associazione del ruolo e per l'account di servizio.
Deployment e utilizzo dell'applicazione web
A questo punto, creerai l'applicazione web e l'immagine container, eseguirai il deployment della nuova dell'immagine container al tuo cluster GKE e aprire il file nel browser per verificare che l'applicazione web possa utilizzare gMSA.
Crea ed esegui il deployment dell'applicazione web ASP.NET
Su
gmsa-dev-vm
, in PowerShell, imposta le variabili per il registro posizione, nome registro e tag immagine:$RegistryLocation = "LOCATION-docker.pkg.dev" $ProjectsRegistry = "$RegistryLocation/$ProjectId" $ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
Sostituisci
LOCATION
con la posizione in cui ha creato il repository Artifact Registry.Crea l'immagine container:
docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
Per creare immagini container per Windows Server 2019, imposta il parametro
-f
suDockerfile-WINDOWS_LTSC2019
.Esegui il push dell'immagine container in Artifact Registry:
gcloud auth configure-docker $RegistryLocation --quiet docker push $ImageTag
Scarica il file YAML dell'applicazione e aggiornalo con il tuo gMSA configurazione:
$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 YAML dell'applicazione e modificare il valore
cloud.google.com/gke-windows-os-version
dalle ore2022
alle ore2019
.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 utilizzando un servizio LoadBalancer
.
Prima di poter passare all'applicazione web, devi attendere che il pod
del servizio di cui eseguire il deployment. Il deployment del pod può richiedere diversi minuti
Le immagini container di Windows Server Core sono grandi (l'immagine dell'applicazione web è
più grandi di 7 GB) e il nodo impiega del tempo per scaricare l'immagine
per creare il container.
Controlla lo stato del pod:
kubectl get pods --selector=app=gmsa-test-webapp-01
Ripeti il comando finché l'output non indica 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 rimane Pending (In attesa) e non passa a ContainerCreating o ContainerCreating, verifica l'immagine di origine del nodo Windows per verificare che sia Windows Server 2022. Puoi anche controllare mappatura delle versioni per vedere come le versioni di GKE vengono mappate a Windows Server e versioni successive. Se le versioni non corrispondono, duplica
Dockerfile-WINDOWS_LTSC2022
, imposta il immagine container di base nel nuovo file in modo che corrisponda alla versione Windows Server dei nodi, quindi ripeti passi per creano ed eseguono il deployment dell'applicazione web ASP.NET.Controlla lo stato del servizio:
kubectl get service --selector=app=gmsa-test-webapp-01
Ripeti il comando finché l'output indica 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
Prendi nota del valore external-ip nell'output; questo valore ti servirà in un secondo momento.
Esegui test preliminari nell'applicazione web ASP.NET
Il pod è ora in esecuzione ed è accessibile da internet attraverso una rete con il bilanciatore del carico di rete passthrough esterno regionale. Successivamente, esegui dei test preliminari per verificare che il container sia il deployment sia andato a buon fine e che disponga delle autorizzazioni necessarie per utilizzare gMSA.
In un browser, vai a
http://EXTERNAL-IP
per visualizzare il gMSA per testare l'applicazione web.Sostituisci
EXTERNAL-IP
con l'indirizzo IP che nella procedura precedente.Scorri fino alla sezione Controlli preflight e fai clic sul pulsante Esegui. Pulsante 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.
Scorri fino alla sezione Informazioni contenitore e fai clic sul pulsante Pulsante Esegui script. Verifica che le informazioni sul contenitore siano visualizzate e il nodo, senza che venga visualizzato alcun errore.
Utilizza gMSA nei container Windows
Ora puoi verificare che la configurazione di gMSA funzioni correttamente eseguendo diverse i test nell'applicazione web. Ciascuno dei test utilizza il gMSA per un che non ha uno scopo specifico. Se tutti i test hanno esito positivo, significa che gMSA è stato configurato correttamente.
Convalida la configurazione del container gMSA
Scorri fino alla sezione Connettività del dominio, digita il nome del tuo gMSA (
WebApp-01
) nella casella Nome account, quindi 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 a gMSA:
Get-ADServiceAccount
: Questo cmdlet recupera le informazioni su 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 comando viene eseguito correttamente, il container è in esecuzione su un nodo Windows Server a cui è consentito accedere alle credenziali gMSA.
Consentire agli utenti di accedere con l'autenticazione di Windows
- Nella barra di navigazione in alto della pagina, fai clic su Accedi.
- Quando ti viene chiesto di inserire le credenziali, inserisci il tuo dominio. nome utente e password.
Se viene visualizzata la pagina Sicurezza con i dati del tuo account e sei non vengono richieste le credenziali, il browser ti ha eseguito automaticamente l'accesso. utilizzando la tua identità attuale.
Una volta eseguita l'autenticazione, vedrai la pagina Sicuro. Assicurati di consulta le tre sezioni seguenti:
- Informazioni utente: mostra il tuo nome utente e il tipo di utilizzata.
- Gruppi: mostra l'elenco dei gruppi a cui appartieni. Il gruppo dei nomi nell'elenco vengono recuperati da Active Directory.
- Rivendicazioni dell'utente: mostra l'elenco delle rivendicazioni dell'utente fornito da Active Directory durante l'accesso. Le rivendicazioni relative all'appartenenza al gruppo mostrano Gruppo Active Directory SID non i loro nomi.
Oltre a supportare Integrated Windows Authentication, il server web ASP.NET può utilizzare il proprio gMSA per l'autenticazione durante la chiamata a server remoti. Utilizzando gMSA, l'applicazione web e qualsiasi altra applicazione in esecuzione Il container Windows può accedere alle risorse nella rete che richiedono Windows dei nodi, come le istanze SQL Server e le condivisioni di rete basate su SMB.
Risoluzione dei problemi
Se viene visualizzato un messaggio di errore durante il processo di configurazione o durante i test l'applicazione web, consulta le seguenti pagine per la risoluzione dei problemi:
- Risoluzione dei problemi di Windows Server su GKE
- documentazione di Kubernetes su risoluzione dei problemi dei container Windows Server
- Documentazione Microsoft su Risoluzione dei problemi relativi a 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 per agli scopi del tutorial. Per un ambiente di produzione, puoi apportare modifiche di alcune procedure per rendere i risultati più affidabili, come descritto le sezioni seguenti.
Considerazioni sui pool di nodi di Windows Server
Se prevedi di eseguire il deployment della tua applicazione che utilizza un gMSA e supporta le sessioni client, ti consigliamo di creare almeno due di nodi nel pool di nodi. Avere più nodi ti consente di usare spazio di archiviazione di sessione per verificare che l'applicazione sia in grado di gestire sessioni distribuite correttamente.
In questo tutorial, creerai un singolo pool di nodi Windows Server per ospitare
diverse applicazioni. Tuttavia, potrebbero verificarsi delle situazioni in cui vuoi creare
più pool di nodi Windows Server nel tuo cluster, ad esempio un pool di nodi.
con dischi permanenti (DP) HDD e un altro pool di nodi con DP SSD. Se hai bisogno
per eseguire il deployment dell'applicazione in più pool di nodi, fornisci un array di
La directory raggruppa gli oggetti nell'PrincipalsAllowedToRetrieveManagedPassword
, quando
crea il gMSA
utilizzando il cmdlet New-ADServiceAccount
.
gMSA e considerazioni sul nome entità di servizio (SPN)
Se la tua applicazione richiede l'autenticazione degli utenti utilizzando Kerberos (ad
esempio per supportare la delega delle identità), dovrai accedere al tuo
utilizzando un DNS personalizzato e configurare gMSA con
nome entità servizio (SPN).
Ad esempio, se il bilanciatore del carico espone l'applicazione
GKE tramite https://my-web-app/
, devi creare
un SPN denominato HTTP/my-web-app
in uno dei seguenti modi:
Per un nuovo gMSA, creane uno 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 il 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, potrebbe essere necessario creare anche un SPN per
HTTP/www.my-web-app
e HTTP/www.my-web-app.$AdDomain
.
Per protocolli non HTTP, ad esempio un servizio WCF configurato con TCP
e autenticazione di 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,
configurare 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
. IIS
i pool di applicazioni forniscono la configurazione del processo, ad esempio se il processo è
un processo a 32 o 64 bit e forniscono l'identità del processo. Quando
un'applicazione web in un container Windows, imposti il
di elaborazione dell'identità per utilizzare
Servizio di rete
.
Il team identità del pool di applicazioni supportati anche da IIS, non sono obbligatori nei container Windows. La sono stati creati da IIS come mezzo per applicare confine di sicurezza locale quando si eseguono più applicazioni web sulla stessa istanza IIS. Con finestre di container, in cui ogni applicazione web è ospitata in un container separato, non occorre creare un confine di sicurezza all'interno del container, il container stesso fornisce il confine di sicurezza.
Anche se l'identità del pool di applicazioni è configurata per utilizzare la rete Account di servizio, se l'applicazione invia una richiesta a una risorsa esterna che richiede l'autenticazione, l'applicazione esegue l'autenticazione mediante il gMSA che 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.
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Rimozione di singole risorse
Se vuoi conservare il progetto Google Cloud, ma non vuoi eliminare Puoi rimuovere le risorse Google Cloud che hai creato per questo tutorial le risorse singolarmente.
Annullare le modifiche ad Active Directory
- Collegati alla VM di sviluppo e accedi come utente con accesso amministrativo al dominio Active Directory.
Nella VM
gmsa-dev-vm
, se PowerShell non è già aperto, aprilo:PowerShell
Elimina il gMSA:
Remove-ADServiceAccount -Identity "WebApp-01" -Confirm:$false
Elimina risorse cloud
In the Google Cloud console, activate Cloud Shell.
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 del tuo progetto Google Cloud.ZONE-NAME
: la zona in cui hai eseguito il deployment il cluster GKE e la VM di sviluppo.LOCATION
: la regione in cui hai eseguito il deployment nel repository di Artifact Registry.
Elimina la VM di sviluppo:
gcloud compute instances delete gmsa-dev-vm --quiet
Elimina l'account di servizio:
gcloud iam service-accounts delete dev-vm@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --quiet
Elimina il cluster GKE:
gcloud container clusters delete cluster-1 --quiet
Se hai creato una regola firewall per i controller Active Directory, Per eliminarlo:
gcloud compute firewall-rules delete allow-gke-pods-to-ad --quiet
Elimina il repository Docker di Artifact Registry:
gcloud artifacts repositories delete windows-container-images --quiet
Per terminare, segui i passaggi di pulizia in Configurazione di Active Directory per fare in modo che le VM vengano aggiunte automaticamente a un dominio.
Passaggi successivi
- Informazioni Container Windows Server su GKE.
- Informazioni su creazione di un cluster GKE utilizzando i pool di nodi di Windows Server.
- Leggi altri modi per distribuire le applicazioni Windows Server.
- Consulta le nostre best practice per il deployment di una foresta di risorse Active Directory su Google Cloud.