Ce tutoriel explique comment créer une application Web ASP.NET utilisant IIS avec l'authentification Windows intégrée et comment la déployer à l'aide d'un conteneur Windows sur un cluster Google Kubernetes Engine (GKE) qui comporte des nœuds Windows Server joints à un domaine. Cette configuration est utile pour déployer des applications ASP.NET dans des conteneurs Windows sur Google Cloud afin que les applications puissent s'authentifier auprès d'autres ressources Windows. Ce tutoriel indique également comment créer un compte de service géré de groupe (gMSA) dans Active Directory et comment configurer le déploiement de l'application Web dans GKE pour l'utiliser.
Ce tutoriel est destiné aux administrateurs système. Nous partons du principe que vous connaissez Active Directory et que vous avez déjà travaillé avec Google Kubernetes Engine (GKE).
Objectifs
- Créer un cluster GKE comportant des nœuds Windows Server joints à un domaine et configurer le cluster pour qu'il soit compatible avec les gMSA Active Directory.
- Créer et déployer une image de conteneur d'application Web ASP.NET utilisant le serveur IIS avec l'authentification Windows intégrée
Coûts
Dans ce document, vous utilisez les composants facturables suivants de 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:
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Avant de commencer
Suivez les étapes du tutoriel Configurer Active Directory pour permettre aux VM de s'associer automatiquement à un domaine afin de créer le service Cloud Run pour rejoindre un domaine Active Directory.
Si vous exécutez ce tutoriel dans un autre projet Google Cloud que celui dans lequel vous avez créé une VM pour tester la jonction automatique à un domaine, suivez les étapes de la section Activer la jonction automatique à un domaine au niveau d'un projet dans votre projet Google Cloud.
Une fois l'autre tutoriel terminé, vous disposez d'un nouveau service Cloud Run et son URL est affichée dans la fenêtre PowerShell (la valeur de la variable
$RegisterUrl
). Notez l'adresse du service, car vous l'utiliserez dans ce tutoriel.Assurez-vous d'avoir activé les API pour Compute Engine, GKE, Cloud Build, Artifact Registry et Cloud Resource Manager :
Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.
Architecture
Les applications Windows qui s'exécutent dans un serveur Windows Server associé à un domaine utilisent souvent les identités Microsoft Active Directory (AD) pour authentifier les utilisateurs et les applications. Voici quelques cas d'utilisation courants:
- Créer des applications Web ASP.NET utilisant l'authentification Windows intégrée pour authentifier les utilisateurs Active Directory lorsqu'ils tentent de se connecter à l'application Web.
- Créer des applications qui utilisent le compte d'ordinateur Active Directory du serveur pour accéder aux ressources du réseau, telles qu'un partage SMB distant ou une instance Microsoft SQL Server distante.
Les conteneurs Windows ne peuvent pas être joints à un domaine et ne disposent donc pas de comptes d'ordinateur dans Active Directory. De ce fait, les applications Web ASP.NET qui s'exécutent sur des conteneurs Windows ne peuvent pas authentifier les utilisateurs Active Directory via l'authentification Windows intégrée et ne peuvent donc pas accéder aux ressources sécurisées du réseau. Pour en savoir plus sur la manière dont ASP.NET accède aux ressources sécurisées, consultez la section Identités du pool d'applications dans la documentation Microsoft.
Au lieu d'utiliser un compte d'ordinateur, les conteneurs Windows peuvent utiliser une identité de compte de service géré (gMSA) de groupe Active Directory pour accéder à Active Directory et à d'autres ressources sécurisées du réseau, telles que les partages de fichiers et les instances SQL Server. Pour en savoir plus, consultez la page Présentation des comptes de service gérés de groupe dans la documentation Microsoft.
Le schéma d'architecture suivant présente les ressources utilisées dans ce tutoriel:
Le schéma montre les éléments suivants:
- VM de développement. Dans ce tutoriel, vous allez créer une VM Windows Server que vous utiliserez pour créer l'image de conteneur d'application Web ASP.NET et pour créer le gMSA.
- Nœuds et cluster GKE. Dans ce tutoriel, le cluster GKE dispose d'un pool de nœuds Linux et d'un pool de nœuds Windows Server, utilisés de la manière suivante :
- Les nœuds Linux exécutent des composants système qui ne s'exécutent que sur les systèmes d'exploitation Linux, tels que le serveur de métriques GKE.
- Les nœuds Windows Server sont utilisés pour héberger des conteneurs Windows Server et sont associés à un domaine Active Directory.
- Infrastructure Active Directory Pour associer les nœuds Windows GKE à un domaine, vous devez d'abord suivre le tutoriel Configurer Active Directory pour permettre aux VM de s'associer automatiquement à un domaine. Dans ce tutoriel, vous allez créer un service Cloud Run responsable de l'enregistrement de nouveaux ordinateurs (instances) dans Active Directory et de fournir à chaque nouvelle instance un mot de passe temporaire que l'instance utilise pour effectuer la jonction à un domaine. Chaque nouvelle instance du pool de nœuds Windows Server appelle le service Cloud Run pour se joindre au domaine Active Directory.
- Équilibreur de charge réseau Lorsqu'un utilisateur sur site ouvre son navigateur et accède à l'application Web ASP.NET, le trafic passe par un équilibreur de charge réseau. L'équilibreur de charge est créé par GKE lorsque vous créez un service GKE LoadBalancer pour votre application Web. L'utilisateur s'authentifie également auprès de l'application Web en transmettant ses identifiants Active Directory à celle-ci.
Créer l'infrastructure
Une fois le tutoriel associé terminé, vous devez créer les composants d'infrastructure du tutoriel en cours, qui comprend les éléments suivants:
- Une VM Windows Server qui comporte une image de conteneur d'application Web ASP.NET.
- Un cluster GKE comportant un pool de nœuds Windows Server.
- Règles de pare-feu qui permettent aux pods GKE d'accéder à Active Directory.
- Webhook dans le cluster GKE qui gère la configuration et le remplissage des ressources gMSA dans les déploiements.
Créer une VM de développement
L'image de conteneur Windows Server que vous créez doit correspondre à la version Windows Server de la VM sur laquelle vous créez l'image de conteneur. Cette version doit également correspondre à la version Windows Server de vos nœuds Windows Server GKE. La création d'une image de conteneur ou l'exécution d'un conteneur dans une version différente de Windows Server génère une erreur. Pour en savoir plus sur les exigences de compatibilité des conteneurs Windows, consultez la section Mise en correspondance de la version d'hôte de conteneurs et de la version d'image de conteneur.
Ce tutoriel utilise la version LTSC (Long-Term Servicing Channel 2022) de Windows Server pour la VM, les nœuds Windows Server dans GKE et l'image de conteneur. Pour en savoir plus, consultez le mappage des versions entre les versions de Windows Server et les versions de 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.
- Si PowerShell est ouvert, fermez-le en saisissant
exit
. Définissez des variables d'environnement pour le nom du réseau et du sous-réseau, ainsi que pour l'URL du service Active Directory:
export NETWORK_NAME=NETWORK-NAME export SUBNETWORK_NAME=SUBNETWORK-NAME export AD_JOIN_SERVICE_URL=AD-JOIN-SERVICE-URL
Remplacez l'élément suivant :
NETWORK-NAME
: réseau VPC dans lequel déployer les VM.SUBNETWORK-NAME
: le sous-réseau dans lequel déployer les VMAD-JOIN-SERVICE-URL
: URL du service Cloud Run que vous avez déployé dans la section Avant de commencer.
Définissez l'ID et la région de votre projet Google Cloud pour l'environnement actuel:
gcloud config set project PROJECT-ID gcloud config set compute/zone ZONE-NAME
Remplacez l'élément suivant :
PROJECT-ID
: ID de votre projet Google Cloud.ZONE-NAME
: la zone dans laquelle déployer toutes les VM. Pour réduire la latence, nous vous recommandons de sélectionner une zone dans la même région que celle où vous avez déployé le service Cloud Run de jointure de domaine Active Directory.
Créez un compte de service pour la VM de développement:
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"
Accordez au compte de service l'accès à Artifact Registry :
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \ --role="roles/artifactregistry.writer"
Accordez au compte de service l'accès à GKE:
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \ --role="roles/container.admin"
Le compte de service se voit attribuer le rôle
container.admin
, car ce rôle est autorisé à créer des clusters GKE dans le projet et à gérer des ressources dans les clusters, y compris des ressources de contrôle d'accès basé sur les rôles (RBAC). Les ressources RBAC sont nécessaires pour contrôler quel pod est autorisé à utiliser un gMSA.Créez une 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"
Si vous prévoyez de déployer vos applications conteneurisées vers des conteneurs Windows Server 2019, remplacez la valeur du paramètre
--image-family
parwindows-2019-core-for-containers
.Le champ d'application
https://www.googleapis.com/auth/cloud-platform
permet à l'instance d'accéder à toutes les API Google Cloud, en fonction des rôles IAM définis pour le compte de service de l'instance.La VM est créée avec une adresse IP externe pour lui permettre de communiquer avec Internet. Vous avez besoin que la VM dispose d'un accès à Internet pour télécharger plusieurs utilitaires, tels que git et kubectl et télécharger l'application Web ASP.NET à partir de GitHub.
Au cours de l'étape
sysprep
, la nouvelle instance est associée au domaine Active Directory afin de vous permettre d'y accéder à distance à l'aide de votre compte de domaine. Le script de la commandesysprep
installe également le module PowerShell pour Active Directory.
Créer un dépôt Docker Artifact Registry
Dans Cloud Shell, définissez l'emplacement par défaut pour les nouveaux dépôts Artifact Registry :
gcloud config set artifacts/location LOCATION
Remplacez
LOCATION
par une région dans laquelle vous souhaitez créer le dépôt Artifact Registry. Pour réduire la latence, nous vous recommandons de sélectionner la même région que celle où vous avez déployé la VM de développement.Créez le dépôt Docker Artifact Registry :
gcloud artifacts repositories create windows-container-images \ --repository-format=docker
Créer un cluster GKE
Dans Cloud Shell, définissez une variable d'environnement pour le nom du cluster GKE:
export GKE_CLUSTER_NAME=cluster-1
Créez le cluster GKE :
gcloud container clusters create $GKE_CLUSTER_NAME \ --release-channel rapid \ --network $NETWORK_NAME \ --subnetwork $SUBNETWORK_NAME \ --enable-ip-alias
La définition du paramètre
--release-channel
surrapid
déploie le cluster GKE avec la dernière version de Kubernetes. Le paramètre--enable-ip-alias
active les adresses IP d'alias. L'adresse IP d'alias est obligatoire pour les nœuds Windows Server.
Créer un pool de nœuds Windows Server dans GKE
Lorsque vous créez un cluster GKE via la CLI, le cluster est créé avec un pool de nœuds Linux. Pour utiliser Windows Server sur GKE, vous devez créer un pool de nœuds Windows Server.
Les clusters GKE doivent disposer d'au moins un nœud Linux pour exécuter les conteneurs internes (système) du cluster. Un cluster GKE ne peut être créé qu'avec des nœuds Windows Server.
Dans Cloud Shell, définissez une variable d'environnement pour le nom du pool de nœuds du serveur Windows:
export NODE_POOL_NAME=windows-server-pool
Créez un pool de nœuds 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'))"
Si vous envisagez de déployer vos applications conteneurisées vers des conteneurs Windows Server 2019, définissez le paramètre
--windows-os-version
surltsc2019
.La clé de métadonnées
sysprep-specialize-script-ps1
est une clé intégrée qui pointe vers un script PowerShell exécuté lors de l'étape GCESysprep, avant que l'instance ne démarre pour la première fois.Le cmdlet
iex
télécharge le script PowerShell à partir du service de jointure de domaine Active Directory que vous avez déployé sur Cloud Run. Il exécute ensuite le script qui joint la nouvelle instance au domaine Active Directory.Le paramètre
--no-enable-autoupgrade
désactive la mise à niveau automatique des nœuds pour tous les nœuds du pool. Cette opération est nécessaire, car la mise à niveau de l'image Windows d'un nœud peut entraîner une incompatibilité entre la version Windows Server du nœud et celle du pod. Pour en savoir plus, consultez la page Mettre à niveau les pools de nœuds Windows Server.Une fois que chaque nœud est créé, le script PowerShell
domain-join
le joint au domaine.Attendez plusieurs minutes jusqu'à ce que le pool de nœuds soit créé, puis exécutez la commande suivante pour vérifier que tous les nœuds ont rejoint le domaine:
kubectl get node \ -l cloud.google.com/gke-nodepool=$NODE_POOL_NAME \ -o custom-columns=":metadata.name" --no-headers \ | xargs -I{} gcloud compute instances get-serial-port-output {} --port 1 \ | grep "sysprep-specialize-script-ps1:.*success" --ignore-case
Si les nœuds ont été associés au domaine, le résultat est le suivant:
timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Successfully registered computer account. timestamp GCEMetadataScripts: sysprep-specialize-script-ps1: Computer successfully joined to domain Specify --start=152874 in the next get-serial-port-output invocation to get only the new output starting from here.
Si vous souhaitez voir la sortie complète du script, supprimez
.*success
de la commandegrep
.
Accorder aux pods GKE l'accès à Active Directory
Vous devez créer une règle de pare-feu permettant aux pods du cluster GKE d'accéder à vos contrôleurs de domaine à l'aide des protocoles suivants:
- 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)
- Services Web Active Directory (TCP/9389)
Vous pouvez appliquer la règle basée sur un compte de service que vous avez attribué à vos contrôleurs de domaine, ou bien vous pouvez l'appliquer en utilisant un tag réseau, comme c'est le cas dans ce tutoriel. Pour en savoir plus sur les ports associés à Active Directory, consultez la documentation sur la Configuration requise pour le port et le protocole Active Directory et sur l'utilisation d'Active Directory sur les pare-feu.
Si vous utilisez le service géré pour Microsoft Active Directory (Microsoft AD géré), vous pouvez ignorer cette procédure.
Dans Cloud Shell, obtenez la plage d'adresses IP des pods du cluster GKE:
CLUSTER_IP_RANGE=`gcloud container clusters describe $GKE_CLUSTER_NAME --format="value(clusterIpv4Cidr)"`
Créez une règle de pare-feu pour autoriser les pods GKE à accéder à 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
Remplacez
DC-TAG
par le tag réseau attribué aux VM de vos contrôleurs de domaine.
Configurer GKE pour prendre en charge l'utilisation de gMSA
Pour utiliser un gMSA sur les nœuds Windows Server, vous devez créer l'objet gMSA dans Active Directory, créer une ressource gMSA correspondante dans GKE et autoriser les pods nouvellement créés à récupérer leurs identifiants gMSA.
Dans Cloud Shell, téléchargez et exécutez le script webhook de gMSA:
export K8S_GMSA_DEPLOY_DOWNLOAD_REV=b685a27adc40511bb5756dfb3ada2e8578ee72e1 curl https://raw.githubusercontent.com/kubernetes-sigs/windows-gmsa/$K8S_GMSA_DEPLOY_DOWNLOAD_REV/admission-webhook/deploy/deploy-gmsa-webhook.sh -o deploy-gmsa-webhook.sh && chmod +x deploy-gmsa-webhook.sh ./deploy-gmsa-webhook.sh --file ./gmsa-webhook.yml --namespace gmsa-webhook --overwrite rm -drf gmsa-webhook-certs
Le script ajoute le fichier manifeste CRD (Custom Resource Definition) gMSA à votre cluster GKE et déploie un webhook qui fournit les spécifications du gMSA aux pods. Vous pouvez maintenant stocker les spécifications de gMSA dans votre cluster et configurer des gMSA pour les pods et les conteneurs.
Pour en savoir plus sur Kubernetes et les gMSA, consultez la section Configurer GMSA pour les conteneurs et les pods Windows.
Votre cluster GKE est maintenant prêt à exécuter des applications Windows nécessitant l'utilisation d'un compte de service gMSA. Par exemple, vous pouvez exécuter une application Web ASP.NET dans vos nœuds Windows Server. Vous pouvez configurer l'application pour qu'elle connecte les utilisateurs à l'aide de l'authentification Windows ou qu'elle utilise le compte de service gMSA du pod pour accéder à un partage réseau à distance ou à une base de données SQL Server.
Intégrer Active Directory
Vous devez ensuite créer un compte de service gMSA pour votre application Web ASP.NET dans Active Directory, configurer son utilisation et son auteur, puis ajouter sa configuration à GKE.
Se connecter et démarrer PowerShell
- Connectez-vous à la VM
gmsa-dev-vm
. Connectez-vous à Windows à l'aide d'un compte Active Directory autorisé à créer un compte de service gMSA.
Votre compte doit être membre du groupe
Domain Admins
ou pouvoir créer des objetsmsDS-GroupManagedServiceAccount
. Pour en savoir plus, consultez la page Provisionner des comptes de service gérés de groupes.Si vous utilisez le service Microsoft AD géré, votre compte doit être membre du groupe
Cloud Service Managed Service Account Administrators
. Pour en savoir plus, consultez la page Déléguer l'administration des comptes de service gérés.Saisissez
15
pour quitter le menu et accéder à la ligne de commande (PowerShell).
Installer un environnement d'exécution de conteneur
Windows Server 2022 nécessite un environnement d'exécution de conteneur, tel que Docker Community Edition (CE), pour créer et exécuter des conteneurs Windows. Pour en savoir plus sur l'installation d'un environnement d'exécution de conteneur sur Windows Server, consultez la section Premiers pas : préparer Windows pour les conteneurs dans la documentation Microsoft.
Si vous avez créé la VM de développement à l'aide de l'image windows-2019-core-for-containers
, vous pouvez ignorer la procédure suivante, car Docker est déjà installé sur l'image.
Installez Docker Community Edition (CE) :
Invoke-WebRequest -UseBasicParsing -o install-docker-ce.ps1 ` "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" .\install-docker-ce.ps1
Si la connexion Bureau à distance se ferme pendant le processus d'installation, reconnectez-vous à la VM.
Attendez la fin du processus d'installation, puis saisissez
exit
pour fermer la nouvelle fenêtre PowerShell.Saisissez
15
pour quitter le menu et accéder à la ligne de commande (PowerShell).
Créer une clé racine KDS
Avant de créer un compte de service gMSA, vous devez vous assurer que votre contrôleur de domaine Active Directory possède une clé racine KDS (Key Distribution Services). Active Directory utilise la clé racine KDS afin de générer des mots de passe pour les comptes de service gMSA.
Si vous utilisez le service Microsoft AD géré, vous pouvez ignorer la procédure suivante, car ce dernier crée la clé racine KDS lors de la création du domaine.
Sur
gmsa-dev-vm
, vérifiez si Active Directory dispose déjà de la clé racine KDS:Get-KdsRootKey
Cette commande affiche l'ID de clé s'il existe.
Si vous n'obtenez pas d'ID de clé dans la réponse, créez la clé:
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
Créer le compte de service gMSA
Lorsque vous créez un compte de service gMSA, vous devez fournir les noms des ordinateurs qui ont accès à ce compte. Une bonne pratique de sécurité consiste à n'accorder l'autorisation au compte de service gMSA qu'aux instances dans lesquelles votre application s'exécute. Lorsque vous créez un pool de nœuds Windows Server associé à un domaine, un groupe Active Directory est créé pour les ordinateurs du pool de nœuds. Le nom du groupe correspond au nom du groupe d'instances géré (MIG) que GKE crée pour le pool de nœuds.
Dans PowerShell, définissez des variables pour l'ID de projet Google Cloud, le nom du cluster, le nom du pool de nœuds Windows, le nom du service gMSA et le nom de domaine AD:
$ProjectId = "PROJECT-ID" $GkeClusterName = "cluster-1" $PermittedNodePool = "windows-server-pool" $GmsaName = "WebApp-01" $AdDomain = (Get-ADDomain).DNSRoot
Remplacez
PROJECT-ID
par l'ID de votre projet Google Cloud.Définissez la configuration du cluster pour l'outil
gcloud
:gcloud config set project $ProjectId gcloud config set compute/zone "ZONE-NAME"
Remplacez
ZONE-NAME
par la zone dans laquelle vous avez déployé le cluster GKE.Récupérez le nom de domaine du groupe Active Directory créé pour le pool de nœuds:
$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
Créez le compte de service gMSA:
New-ADServiceAccount -Name $GmsaName ` -DNSHostName "$GmsaName.$AdDomain" ` -PrincipalsAllowedToRetrieveManagedPassword $GroupDN
Vérifiez que le compte de service gMSA a été créé:
Get-ADServiceAccount -Identity $GmsaName
Si le compte de service gMSA a été créé, le résultat est semblable à celui-ci:
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 :
Ajouter le compte de service gMSA à GKE
Pour utiliser un compte de service gMSA dans un cluster Kubernetes, vous devez créer une ressource de compte de service gMSA dans Kubernetes, et configurer les espaces de noms et les comptes autorisés à l'utiliser.
Sous
gmsa-dev-vm
, dans PowerShell, installez l'outilgit
:Install-Script -Name Install-Git -Force Install-Git.ps1 $env:Path += ";c:\program files\git\bin"
Installez l'outil
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"
Installez le binaire
gke-gcloud-auth-plugin
:gcloud components install gke-gcloud-auth-plugin
Attendez quelques minutes que le processus d'installation se termine.
Initialisez l'outil
kubectl
avec les identifiants de votre cluster GKE:gcloud container clusters get-credentials $GkeClusterName
Créez le fichier de spécifications des identifiants 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
Le nom de la ressource
GMSACredentialSpec
dans Kubernetes doit utiliser des minuscules.Le script modifie l'utilisation des majuscules de la variable
$GmsaName
pour respecter cette restriction.Le script affiche un message d'avertissement indiquant que le test du compte de service géré a échoué, ce qui est normal. Votre VM de développement n'est pas membre du groupe attribué au gMSA. Par conséquent, vous ne pouvez pas tester le gMSA à partir de la VM. Le message d'avertissement n'empêche pas la commande de générer la spécification des identifiants gMSA.
Ajoutez la spécification des identifiants gMSA au cluster GKE:
kubectl apply -f $CredSpecFile
Clonez le dépôt GitHub.
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples cd kubernetes-engine-samples/windows/aspnet-gmsa/
Ajoutez les objets RBAC gMSA à votre cluster:
kubectl apply -f gmsa-rbac-webapp-01.yaml
Le fichier
gmsa-rbac-webapp-01.yaml
crée un objet RBACClusterRole
pour le compte de service gMSA, puis lie le nouveau rôle de cluster au compte de service par défaut dans l'espace de nomsdefault
. Si vous déployez votre application dans un autre espace de noms, modifiez le fichiergmsa-rbac-webapp-01.yaml
et modifiez l'espace de noms pour la liaison de rôle et pour le compte de service.
Déployer et utiliser l'application Web
Ensuite, vous devez créer l'application Web et l'image de conteneur, déployer la nouvelle image de conteneur sur votre cluster GKE, puis ouvrir cette application dans le navigateur pour vérifier que l'application Web peut utiliser le compte de service gMSA.
Créer et déployer l'application Web ASP.NET
Sur
gmsa-dev-vm
, dans PowerShell, définissez des variables pour l'emplacement du registre, le nom du registre et le tag de l'image :$RegistryLocation = "LOCATION-docker.pkg.dev" $ProjectsRegistry = "$RegistryLocation/$ProjectId" $ImageTag = "$ProjectsRegistry/windows-container-images/test-gmsa:latest"
Remplacez
LOCATION
par l'emplacement dans lequel vous avez créé le dépôt Artifact Registry.Créez l'image du conteneur :
docker build -t $ImageTag -f Dockerfile-WINDOWS_LTSC2022 .
Pour créer des images de conteneur pour Windows Server 2019, définissez la valeur du paramètre
-f
surDockerfile-WINDOWS_LTSC2019
.Transférer l'image de conteneur vers Artifact Registry :
gcloud auth configure-docker $RegistryLocation --quiet docker push $ImageTag
Téléchargez le fichier YAML de l'application et mettez-le à jour avec votre configuration gMSA:
$ApplicationYaml = Join-Path $env:TEMP "gmsa-test-webapp-01.yaml" (Get-Content gmsa-test-webapp-01.yaml.template) ` -Replace '\${image_path}',$ImageTag | ` Set-Content $ApplicationYaml
Si vous créez des nœuds Windows Server 2019 dans GKE, modifiez le fichier YAML de l'application et remplacez la valeur de
cloud.google.com/gke-windows-os-version
(2022
) par2019
.Déployez l'application Web sur votre cluster GKE:
kubectl apply -f $ApplicationYaml
Vérifier que l'application Web ASP.NET est en cours d'exécution
L'application Web est exposée à Internet à l'aide d'un service LoadBalancer
.
Pour accéder à l'application Web, vous devez attendre le déploiement du pod et du service. Le déploiement du pod peut prendre plusieurs minutes, car les images du conteneur Windows Server Core sont volumineuses (l'image de l'application Web dépasse 7 Go). Par ailleurs, le téléchargement de l'image et la création du conteneur par le pad prennent du temps.
Vérifiez l'état du pod:
kubectl get pods --selector=app=gmsa-test-webapp-01
Répétez la commande jusqu'à ce que le résultat indique que le pod affiche l'état Running (En cours d'exécution) :
NAME READY STATUS RESTARTS AGE gmsa-test-webapp-01-76c6d64975-zrtgq 1/1 Running 0 28s
Si le statut du pod reste En attente et ne passe pas à ContainerCreating ou Running, cochez la case image source de votre nœud Windows pour vous assurer qu'il s'agit bien de Windows Server 2022. Vous pouvez également consulter le tableau Mappage des versions pour voir comment les versions de GKE sont mappées aux versions de Windows Server. Si les versions ne correspondent pas, dupliquez le fichier
Dockerfile-WINDOWS_LTSC2022
, définissez l'image de conteneur de base dans le nouveau fichier pour qu'elle corresponde à la version de Windows Server de vos nœuds, puis répétez les étapes de création et de déploiement de l'application Web ASP.NET.Vérifiez l'état du service:
kubectl get service --selector=app=gmsa-test-webapp-01
Répétez la commande jusqu'à ce que le résultat indique que le service possède une adresse IP externe:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE gmsa-test-webapp-01 LoadBalancer 10.44.2.112 external-ip 80:32233/TCP 17s
Notez la valeur external-ip dans la sortie. vous aurez besoin de cette valeur plus tard.
Exécuter des tests préliminaires dans l'application Web ASP.NET
Le pod est désormais en cours d'exécution et accessible depuis Internet via un équilibreur de charge réseau. Vous allez ensuite exécuter des tests préliminaires pour vérifier que le conteneur a bien été déployé et qu'il est autorisé à utiliser le compte de service gMSA.
Dans un navigateur, accédez à
http://EXTERNAL-IP
pour afficher l'application Web de test gMSA.Remplacez
EXTERNAL-IP
par l'adresse IP que vous avez obtenue à l'étape précédente.Faites défiler la page jusqu'à la section Vérifications préliminaires, puis cliquez sur le bouton Exécuter des vérifications préliminaires pour vérifier que tous les tests ont réussi.
Si les tests réussissent, le résultat est le suivant:
[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.
Faites défiler la page jusqu'à la section Informations sur le conteneur, puis cliquez sur le bouton Exécuter le script. Vérifiez que vous voyez des informations sur le conteneur et le nœud, et qu'aucune erreur ne s'affiche.
Utiliser le compte de service gMSA dans des conteneurs Windows
Vous pouvez maintenant vérifier que la configuration de gMSA fonctionne correctement en exécutant plusieurs tests dans l'application Web. Chacun des tests utilise le compte de service gMSA dans un but différent. Si tous les tests sont concluants, cela signifie que vous avez correctement configuré le compte de service gMSA.
Valider la configuration du conteneur gMSA
Faites défiler la page jusqu'à la sectionConnectivité du domaine saisissez le nom de votre compte de service gMSA (
WebApp-01
) dans la case Nom du compte, puis cliquez sur Exécuter le script. Attendez quelques secondes que les tests se terminent.Le résultat ressemble à ce qui suit :
***** 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 *****
Le script utilise deux cmdlets PowerShell pour tester l'accès au compte de service gMSA:
Get-ADServiceAccount
: ce cmdlet permet de récupérer des informations sur un compte de service gMSA. Si cette commande cmdlt s'exécute correctement, le conteneur s'exécute avec un compte de service gMSA valide.Test-ADServiceAccount
: cette commande cmdlet teste s'il peut récupérer les identifiants gMSA. Si le cmdlt s'exécute correctement, le conteneur s'exécute dans un nœud Windows Server autorisé à accéder aux identifiants gMSA.
Se connecter avec l'authentification Windows
- Dans la barre de navigation en haut de la page, cliquez sur Login (Connexion).
- Lorsque vous êtes invité à saisir vos identifiants, indiquez le nom d'utilisateur et le mot de passe de votre domaine.
Si vous voyez la page Sécurité contenant les informations de votre compte et que vous n'êtes pas invité à saisir vos identifiants, votre navigateur vous a automatiquement connecté à l'aide de votre identité actuelle.
Une fois authentifié, la page Sécurité s'affiche. Assurez-vous de consulter les trois sections suivantes:
- Informations utilisateur: affiche votre nom d'utilisateur et le type d'authentification utilisé.
- Groupes: affiche la liste des groupes auxquels vous appartenez. Les noms de groupe de la liste sont extraits d'Active Directory.
- Revendications utilisateur: affiche la liste des revendications de l'utilisateur telles que fournies par Active Directory lors de la connexion. Les revendications d'appartenance au groupe affichent le SID du groupe Active Directory, et non leur nom.
En plus de la compatibilité avec l'authentification Windows intégrée, l'application Web ASP.NET peut utiliser son compte de service gMSA pour l'authentification lors de l'appel de serveurs distants. À l'aide du gMSA, l'application Web et toute autre application s'exécutant dans le conteneur Windows peuvent accéder aux ressources du réseau nécessitant une authentification Windows, telles que les instances SQL Server et les partages réseau basés sur SMB.
Dépannage
Si vous rencontrez des messages d'erreur au cours du processus de configuration ou pendant le test de l'application Web, consultez les pages de dépannage suivantes:
- Dépannage de Windows Server sur GKE
- Documentation Kubernetes sur le dépannage des conteneurs Windows Server
- Documentation Microsoft sur le dépannage des comptes de service gMSA pour les conteneurs Windows
Autres considérations pour les applications de production
Les instructions que vous avez suivies ont été écrites pour fournir un chemin optimal aux fins du tutoriel. Pour un environnement de production, vous pouvez modifier certaines des procédures afin d'améliorer le résultat, comme décrit dans les sections suivantes.
Considérations relatives au pool de nœuds Windows Server
Si vous envisagez de déployer votre propre application utilisant un compte de service gMSA et que celle-ci accepte les sessions clientes, nous vous recommandons de créer au moins deux nœuds dans le pool de nœuds. Le fait d'avoir plusieurs nœuds vous permet d'utiliser le stockage de session hors processus pour vérifier que votre application peut gérer correctement les sessions distribuées.
Dans ce tutoriel, vous allez créer un pool de nœuds Windows Server unique pour héberger vos applications. Toutefois, vous pouvez être amené à créer plusieurs pools de nœuds Windows Server dans votre cluster, par exemple un pool de nœuds avec des disques persistants HDD et un autre pool de nœuds avec des disques persistants SSD. Si vous devez déployer votre application sur plusieurs pools de nœuds, fournissez un tableau d'objets de groupe Active Directory au paramètre PrincipalsAllowedToRetrieveManagedPassword
lorsque vous créez le compte de service gMSA à l'aide du cmdlet New-ADServiceAccount
.
Considérations relatives au nom de service principal et à gMSA
Si votre application nécessite l'authentification des utilisateurs à l'aide de Kerberos (par exemple, pour prendre en charge la délégation d'identité), vous devez accéder à votre application à l'aide d'un DNS personnalisé et configurer le gMSA avec un nom principal de service (SPN).
Par exemple, si votre équilibreur de charge expose l'application sur GKE via https://my-web-app/
, vous devez créer un SPN nommé HTTP/my-web-app
de l'une des manières suivantes:
Pour un nouveau gMSA, créez le gMSA avec les SPN requis. Exemple :
New-ADServiceAccount -Name $GmsaName ` -DNSHostName "$GmsaName.$AdDomain" ` -PrincipalsAllowedToRetrieveManagedPassword $Groups ` -ServicePrincipalNames "HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"
Pour un gMSA existant, appelez
Set-ADServiceAccount
pour ajouter les SPN requis au gMSA. Exemple :Set-ADServiceAccount $GmsaName -ServicePrincipalNames @{Add="HTTP/my-web-app", "HTTP/my-web-app.$AdDomain"}
En fonction de votre configuration DNS, vous devrez peut-être également créer un SPN pour HTTP/www.my-web-app
et HTTP/www.my-web-app.$AdDomain
.
Pour les protocoles non HTTP, tels qu'un service WCF configuré avec la liaison TCP et l'authentification Windows, vous devrez peut-être créer d'autres types de SPN, tels qu'un SPN HOST/
.
Choisir l'identité du pool d'applications IIS
Les applications Web ASP.NET s'exécutent sous Windows sur le serveur Web IIS. Dans IIS, vous configurez des groupes d'applications Web qui partagent le même processus. Ce groupe est appelé pool d'applications.
Chaque pool d'applications est hébergé dans un processus dédié nommé w3wp
. Les pools d'applications IIS fournissent la configuration du processus, par exemple s'il s'agit d'un processus 32 bits ou 64 bits, et fournissent l'identité du processus. Lorsque vous exécutez une application Web dans un conteneur Windows, vous définissez l'identité du processus du pool d'applications pour qu'elle utilise le compte de service réseau intégré.
Les comptes d'identité d'application de pool locaux, compatibles avec IIS, ne sont pas obligatoires dans les conteneurs Windows. Les comptes d'identité de pool d'applications ont été créés par IIS pour appliquer une limite de sécurité locale lors de l'exécution de plusieurs applications Web sur la même instance IIS. Avec les conteneurs Windows, où chaque application Web est hébergée dans un conteneur distinct, il n'est pas nécessaire de créer une limite de sécurité dans le conteneur, car ce dernier fournit la limite de sécurité.
Même si l'identité du pool d'applications est configurée pour utiliser le compte de service réseau, si l'application envoie une requête à une ressource externe nécessitant une authentification, l'application s'authentifie à l'aide du compte de service gMSA que vous avez configuré pour Conteneur Windows.
Nettoyer
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Supprimer des ressources individuelles
Si vous souhaitez conserver votre projet Google Cloud, mais ne souhaitez pas supprimer les ressources Google Cloud que vous avez créées pour ce tutoriel, vous pouvez les supprimer individuellement.
Annuler les modifications apportées à Active Directory
- Connectez-vous à la VM de développement, en tant qu'utilisateur disposant d'un accès administrateur à votre domaine Active Directory.
Dans la VM
gmsa-dev-vm
, si PowerShell n'est pas déjà ouvert, ouvrez-le:PowerShell
Supprimez le compte de service gMSA:
Remove-ADServiceAccount -Identity "WebApp-01" -Confirm:$false
Supprimer des ressources cloud
In the Google Cloud console, activate Cloud Shell.
Initialisez l'environnement
gcloud
:gcloud config set project PROJECT-ID gcloud config set compute/zone ZONE-NAME gcloud config set artifacts/location LOCATION
Remplacez les éléments suivants :
PROJECT-ID
: ID de votre projet Google Cloud.ZONE-NAME
: zone dans laquelle vous avez déployé le cluster GKE et la VM de développement.LOCATION
: région dans laquelle vous avez déployé le dépôt Artifact Registry.
Supprimez la VM de développement:
gcloud compute instances delete gmsa-dev-vm --quiet
Supprimez le compte de service :
gcloud iam service-accounts delete dev-vm@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --quiet
Supprimez le cluster GKE :
gcloud container clusters delete cluster-1 --quiet
Si vous avez créé une règle de pare-feu pour vos contrôleurs Active Directory, supprimez-la:
gcloud compute firewall-rules delete allow-gke-pods-to-ad --quiet
Supprimez le dépôt Docker Artifact Registry :
gcloud artifacts repositories delete windows-container-images --quiet
Pour terminer, suivez les étapes de nettoyage de la page Configurer Active Directory pour permettre aux VM de s'associer automatiquement à un domaine.
Étape suivante
- Apprenez-en plus sur les conteneurs Windows Server sur GKE.
- Découvrez comment créer un cluster GKE à l'aide de pools de nœuds Windows Server.
- Découvrez d'autres façons de déployer des applications Windows Server.
- Consultez nos bonnes pratiques pour le déploiement d'une forêt de ressources Active Directory dans Google Cloud.