Déployer des applications ASP.NET avec authentification Windows dans des conteneurs Windows pour GKE

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 :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

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

  2. 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.

  3. Assurez-vous d'avoir activé les API pour Compute Engine, GKE, Cloud Build, Artifact Registry et Cloud Resource Manager :

    Activer les API

    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:

Conteneurs Windows Server liés à un domaine Active Domain sur GKE.

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.

  1. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

    En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  2. Si PowerShell est ouvert, fermez-le en saisissant exit.

  3. 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 VM
    • AD-JOIN-SERVICE-URL: URL du service Cloud Run que vous avez déployé dans la section Avant de commencer.

  4. 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.

  5. 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"

  6. 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"

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

  8. 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 en conteneur sur des conteneurs Windows Server 2019, remplacez la valeur du paramètre --image-family par windows-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 commande sysprep installe également le module PowerShell pour Active Directory.

Créer un dépôt Docker Artifact Registry

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

  2. Créez le dépôt Docker Artifact Registry :

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

Créer un cluster GKE

  1. Dans Cloud Shell, définissez une variable d'environnement pour le nom du cluster GKE:

    export GKE_CLUSTER_NAME=cluster-1

  2. 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 sur rapid 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.

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

  2. 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 prévoyez de déployer vos applications conteneurisées dans des conteneurs Windows Server 2019, remplacez le paramètre --windows-os-version par ltsc2019.

    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.

  3. 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 commande grep.

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.

  1. 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)"`

  2. 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.

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

  1. Connectez-vous à la VM gmsa-dev-vm.

  2. 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 objets msDS-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.

  3. Saisissez 15 pour quitter le menu vers 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é.

  1. 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 au bureau à distance se ferme pendant la durée de l'installation, reconnectez-vous à l'instance.

  2. Attendez la fin de l'installation, puis saisissez exit pour fermer la nouvelle fenêtre PowerShell.

  3. Saisissez 15 pour quitter le menu vers 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.

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

  2. 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.

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

  2. 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.

  3. 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

  4. Créez le compte de service gMSA:

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

  5. 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.

  1. Sous gmsa-dev-vm, dans PowerShell, installez l'outil git:

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

  2. 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"

  3. Installez le binaire gke-gcloud-auth-plugin :

    gcloud components install gke-gcloud-auth-plugin

    Patientez quelques minutes pour que le processus d'installation se termine.

  4. Initialisez l'outil kubectl avec les identifiants de votre cluster GKE:

    gcloud container clusters get-credentials $GkeClusterName

  5. 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.

  6. Ajoutez la spécification des identifiants gMSA au cluster GKE:

    kubectl apply -f $CredSpecFile

  7. Clonez le dépôt GitHub.

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

  8. Ajoutez les objets RBAC gMSA à votre cluster:

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

    gmsa-rbac-webapp-01.yaml crée un objet RBAC ClusterRole 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 noms default. Si vous déployez votre application dans un espace de noms différent, modifiez le fichier gmsa-rbac-webapp-01.yaml et modifiez l'espace de noms de la liaison de rôle et du 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

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

  2. 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 sur Dockerfile-WINDOWS_LTSC2019.

  3. Transférer l'image de conteneur vers Artifact Registry :

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

  4. 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 par 2022 par 2019.

  5. 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.

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

  2. 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

  3. 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.

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

  2. 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.

  3. 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

  1. Dans la barre de navigation en haut de la page, cliquez sur Login (Connexion).
  2. Lorsque vous êtes invité à saisir vos identifiants, indiquez le nom d'utilisateur et le mot de passe de votre domaine.

  3. 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:

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.

  1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

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

  1. Connectez-vous à la VM de développement, en tant qu'utilisateur disposant d'un accès administrateur à votre domaine Active Directory.

  2. Dans la VM gmsa-dev-vm, si PowerShell n'est pas déjà ouvert, ouvrez-le:

    PowerShell

  3. Supprimez le compte de service gMSA:

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

Supprimer des ressources cloud

  1. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

  2. 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.

  3. Supprimez la VM de développement:

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

  4. Supprimez le compte de service :

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

  5. Supprimez le cluster GKE :

    gcloud container clusters delete cluster-1 --quiet

  6. 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

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