ASP.NET-Anwendungen mit Windows-Authentifizierung in GKE-Windows-Containern bereitstellen

In dieser Anleitung wird beschrieben, wie Sie eine ASP.NET-Webanwendung erstellen, die IIS mit der integrierten Windows-Authentifizierung verwendet, und sie mit einem Windows-Container in einem GKE-Cluster (Google Kubernetes Engine) mit in die Domain eingebundenen Windows Server-Knoten bereitstellen. Diese Konfiguration ist nützlich für die Bereitstellung von ASP.NET-Anwendungen in Windows-Containern in Google Cloud, sodass sich die Anwendungen bei anderen Windows-Ressourcen authentifizieren können. In dieser Anleitung wird auch gezeigt, wie Sie ein gruppenverwalteten Dienstkonto (group Managed Service Account, gMSA) in Active Directory erstellen und die Bereitstellung der Webanwendung in GKE für die Verwendung konfigurieren.

Diese Anleitung richtet sich an Systemadministratoren. Dabei wird davon ausgegangen, dass Sie mit Active Directory vertraut sind und schon mit Google Kubernetes Engine (GKE) gearbeitet haben.

Ziele

  • GKE-Cluster mit in die Domain eingebundenen Windows-Server-Knoten erstellen und den Cluster für die Unterstützung von Active Directory-gMSAs konfigurieren
  • ASP.NET-Webanwendungs-Container-Image erstellen und bereitstellen, das IIS mit integrierter Windows-Authentifizierung verwendet

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweise

  1. Führen Sie die Schritte in der Anleitung Active Directory für VMs für den automatischen Domainbeitritt konfigurieren aus, um den Active Directory-Cloud Run-Dienst für den Domainbeitritt zu erstellen.

  2. Wenn Sie diese Anleitung in einem anderen Google Cloud-Projekt als dem ausführen, in dem Sie eine VM zum Testen des automatischen Domainbeitritts erstellt haben, führen Sie die Schritte zum Aktivieren des automatischen Domainbeitritts für ein Projekt in Ihrem Google Cloud-Projekt aus.

    Wenn Sie die andere Anleitung abgeschlossen haben, haben Sie einen neuen Cloud Run-Dienst. Seine URL wird im PowerShell-Fenster angezeigt (der Wert der Variable $RegisterUrl). Notieren Sie sich die Adresse des Dienstes, da Sie ihn in dieser Anleitung verwenden.

  3. Prüfen Sie, ob Sie die APIs für Compute Engine, GKE, Cloud Build, Artifact Registry und Cloud Resource Manager API aktiviert haben:

    APIs aktivieren

    Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, wenn Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Architektur

Windows-basierte Anwendungen, die auf einem in die Domain eingebundenen Windows-Server ausgeführt werden, verwenden häufig Microsoft AD-Identitäten (Active Directory), um Nutzer und Anwendungen zu authentifizieren. Gängige Anwendungsfälle dafür:

  • ASP.NET-Webanwendungen erstellen, die die integrierte Windows-Authentifizierung zur Authentifizierung von Active Directory-Nutzern verwenden, wenn sie versuchen, sich bei der Webanwendung anzumelden
  • Anwendungen erstellen, die das Active Directory-Computerkonto des Servers verwenden, um über das Netzwerk auf Ressourcen zuzugreifen, z. B. eine Remote-SMB-Freigabe oder eine Microsoft SQL Server-Remote-Instanz.

Windows-Container können nicht in die Domain eingebunden sein und haben daher keine Computerkonten in Active Directory. Aus diesem Grund können ASP.NET-Webanwendungen, die in Windows-Containern ausgeführt werden, Active Directory-Nutzer nicht über die integrierte Windows-Authentifizierung authentifizieren und daher nicht auf gesicherte Ressourcen im Netzwerk zugreifen. Weitere Informationen dazu, wie ASP.NET auf gesicherte Ressourcen zugreift, finden Sie unter Anwendungspool-Identitäten in der Microsoft-Dokumentation.

Anstelle eines Computerkontos können Windows-Container ein gruppenverwaltetes Dienstkonto (gMSA) von Active Directory verwenden, um auf Active Directory und andere gesicherte Ressourcen im Netzwerk zuzugreifen, z. B. Dateifreigaben und SQL Server-Instanzen. Weitere Informationen finden Sie unter Gruppenverwaltete Dienstkonten – Übersicht in der Microsoft-Dokumentation.

Das folgende Architekturdiagramm zeigt die Ressourcen, die in dieser Anleitung verwendet werden:

Aktive, in die Domain eingebundene Windows Server-Container in GKE

Das Diagramm zeigt die folgenden Elemente:

  • Entwicklungs-VM. In dieser Anleitung erstellen Sie eine Windows Server-VM, die Sie zum Erstellen des Container-Images der ASP.NET-Webanwendung sowie des gMSA verwenden.
  • GKE-Cluster und -Knoten. Der GKE-Cluster in dieser Anleitung hat sowohl einen Linux-Knotenpool als auch einen Windows Server-Knotenpool, die folgendermaßen verwendet werden:
    • Auf den Linux-Knoten werden Systemkomponenten ausgeführt, die nur unter Linux-Betriebssystemen ausgeführt werden, z. B. der GKE-Messwertserver.
    • Die Windows Server-Knoten werden zum Hosten von Windows Server-Containern verwendet und sind mit einer Active Directory-Domain verknüpft.
  • Active Directory-Infrastruktur. Damit die GKE Windows-Knoten in die Domain eingebunden werden, lesen Sie zuerst die Anleitung Active Directory für VMs für den automatischen Domainbeitritt konfigurieren. In dieser Anleitung erstellen Sie einen Cloud Run-Dienst, der für die Registrierung neuer Computer (Instanzen) in Active Directory verantwortlich ist und für jede neue Instanz ein temporäres Passwort angibt, mit dem die Instanz den Prozess des Domainbeitritts abschließt. Jede neue Instanz im Windows Server-Knotenpool ruft den Cloud Run-Dienst auf, um der Active Directory-Domain beizutreten.
  • Netzwerk-Load-Balancer. Wenn ein lokaler Nutzer den Browser öffnet und die ASP.NET-Webanwendung aufruft, wird der Traffic über einen Netzwerk-Load-Balancer geleitet. Der Load-Balancer wird von GKE erstellt, wenn Sie einen GKE-LoadBalancer-Dienst für Ihre Webanwendung erstellen. Der Nutzer authentifiziert sich auch bei der Webanwendung, indem er seine Active Directory-Anmeldedaten an die Webanwendung übergibt.

Infrastruktur erstellen

Nachdem Sie die zugehörige Anleitung abgeschlossen haben, erstellen Sie die Infrastrukturkomponenten für die aktuelle Anleitung, was Folgendes umfasst:

  • Eine Windows Server-VM mit einem Container-Image für die ASP.NET-Webanwendung.
  • Einen GKE-Cluster mit einem Windows Server-Knotenpool.
  • Firewallregeln, die den GKE-Pods Zugriff auf Active Directory gewähren.
  • Einen Webhook im GKE-Cluster, der die Konfiguration und das Füllen von gMSA-Ressourcen in Bereitstellungen durchführt.

Entwicklungs-VM erstellen

Das von Ihnen erstellte Windows Server-Container-Image muss mit der Windows Server-Version der VM übereinstimmen, auf der Sie das Container-Image erstellen. Diese Version muss auch mit der Windows Server-Version Ihrer GKE-Windows Server-Knoten übereinstimmen. Wenn Sie ein Container-Image erstellen oder einen Container in einer anderen Version von Windows Server ausführen, tritt ein Fehler auf. Weitere Informationen zu den Kompatibilitätsanforderungen von Windows-Containern finden Sie unter Container-Host-Version mit Container-Image-Versionen abgleichen.

In dieser Anleitung wird die LTSC-Version (Long-Term Servicing Channel) von 2022 für die VM, die Windows Server-Knoten in GKE und das Container-Image verwendet. Weitere Informationen finden Sie unter Versionszuordnung zwischen Windows Server-Versionen und GKE-Versionen.

  1. In the Google Cloud console, activate Cloud Shell.

    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.

  2. Wenn PowerShell geöffnet ist, schließen Sie es durch Eingabe von exit.

  3. Legen Sie Umgebungsvariablen für den Netzwerk- und Subnetzwerknamen und für die Active Directory-Dienst-URL fest:

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

    Ersetzen Sie Folgendes:

    • NETWORK-NAME: Das VPC-Netzwerk, in dem VMs bereitgestellt werden sollen.
    • SUBNETWORK-NAME: Das Subnetz, in dem VMs bereitgestellt werden sollen.
    • AD-JOIN-SERVICE-URL: Die URL des Cloud Run-Dienstes, den Sie im Abschnitt Hinweis bereitgestellt haben.

  4. Legen Sie Ihre Google Cloud-Projekt-ID und -Region für die aktuelle Umgebung fest:

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

    Ersetzen Sie Folgendes:

    • PROJECT-ID: Ihre Google Cloud-Projekt-ID.
    • ZONE-NAME: Die Zone, in der alle VMs bereitgestellt werden sollen. Zur Verringerung der Latenz empfehlen wir, eine Zone in derselben Region auszuwählen, in der Sie den Active Directory-Cloud Run-Dienst für den Domainbeitritt bereitgestellt haben.

  5. Erstellen Sie ein Dienstkonto für die Entwicklungs-VM:

    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. Gewähren Sie dem Dienstkonto Zugriff auf Artifact Registry:

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

  7. Gewähren Sie dem Dienstkonto Zugriff auf GKE:

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

    Dem Dienstkonto wird die Rolle container.admin zugewiesen, da diese Rolle sowohl zum Erstellen von GKE-Clustern im Projekt als auch zum Verwalten von Ressourcen in Clustern, einschließlich RBAC-Ressourcen (rollenbasierte Zugriffssteuerung), berechtigt ist. RBAC-Ressourcen sind erforderlich, um zu steuern, welcher Pod ein gMSA verwenden darf.

  8. Erstellen Sie eine neue Windows Server 2022-VM:

    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"

    Wenn Sie Ihre Containeranwendungen unter Windows Server 2019-Container bereitstellen möchten, ändern Sie den Wert des Parameters --image-family zu windows-2019-core-for-containers.

    Der Bereich https://www.googleapis.com/auth/cloud-platform ermöglicht der Instanz den Zugriff auf alle Google Cloud APIs, je nach den für das Dienstkonto der Instanz definierten IAM-Rollen.

    Die VM wird mit einer externen IP-Adresse erstellt, um die Kommunikation mit dem Internet zu ermöglichen. Die VM benötigt Internetzugriff, damit mehrere Dienstprogramme, z. B. git und kubectl, sowie die ASP.NET-Webanwendung von GitHub heruntergeladen werden können.

    In der sysprep-Phase wird die neue Instanz mit der Active Directory-Domain verknüpft, damit Sie über Ihr Domainkonto per Remotezugriff auf die Instanz zugreifen können. Das Skript im Befehl sysprep installiert auch das PowerShell-Modul für Active Directory.

Artifact Registry-Docker-Repository erstellen

  1. Legen Sie in Cloud Shell den Standardspeicherort für neue Artifact Registry-Repositories fest:

    gcloud config set artifacts/location LOCATION

    Ersetzen Sie LOCATION durch eine Region, in der Sie das Artifact Registry-Repository erstellen möchten. Zur Verringerung der Latenz empfehlen wir, dieselbe Region auszuwählen, in der Sie die Entwicklungs-VM bereitgestellt haben.

  2. Artifact Registry-Docker-Repository erstellen:

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

GKE-Cluster erstellen

  1. Legen Sie in Cloud Shell eine Umgebungsvariable für den Namen des GKE-Clusters fest:

    export GKE_CLUSTER_NAME=cluster-1

  2. Erstellen Sie den GKE-Cluster:

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

    Wenn Sie den Parameter --release-channel auf rapid festlegen, wird der GKE-Cluster mit der neuesten Kubernetes-Version bereitgestellt. Der Parameter --enable-ip-alias aktiviert die Alias-IP-Adresse. Für Windows Server-Knoten ist eine Alias-IP-Adresse erforderlich.

Windows Server-Knotenpool in GKE erstellen

Wenn Sie einen neuen GKE-Cluster über die Befehlszeile erstellen, wird der Cluster mit einem Linux-Knotenpool erstellt. Zur Verwendung von Windows Server in GKE erstellen Sie einen Windows Server-Knotenpool.

GKE-Cluster benötigen mindestens einen Linux-Knoten, um die internen (System-)Container des Clusters auszuführen. Ein GKE-Cluster kann nicht allein mit Windows Server-Knoten erstellt werden.

  1. Legen Sie in Cloud Shell eine Umgebungsvariable für den Namen des Windows Server-Knotenpools fest:

    export NODE_POOL_NAME=windows-server-pool

  2. Erstellen Sie einen GKE-Windows Server-Knotenpool:

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

    Wenn Sie Ihre containerisierten Anwendungen in Windows Server 2019-Containern bereitstellen möchten, ändern Sie den Parameter --windows-os-version in ltsc2019.

    Der Metadatenschlüssel sysprep-specialize-script-ps1 ist ein integrierter Schlüssel, der auf ein PowerShell-Skript verweist, das während des Vorgangs GCESysprep ausgeführt wird, bevor die Instanz zum ersten Mal gestartet wird.

    Das Cmdlet iex lädt das PowerShell-Skript aus dem Active Directory-Domainbeitrittsdienst herunter, den Sie in Cloud Run bereitgestellt haben. Anschließend wird das Skript ausgeführt, mit dem die neue Instanz mit der Active Directory-Domain verknüpft wird.

    Der Parameter --no-enable-autoupgrade deaktiviert das automatische Knotenupgrade für alle Knoten im Pool. Dies geschieht, weil das Upgrade des Windows-Images eines Knotens zu einer Inkompatibilität zwischen der Windows Server-Version des Knotens und der Windows Server-Version des Pods führen kann. Weitere Informationen finden Sie unter Windows Server-Knotenpools upgraden.

    Nachdem jeder Knoten erstellt wurde, verknüpft das domain-join-PowerShell-Skript den Knoten mit der Domain.

  3. Warten Sie einige Minuten, bis der Knotenpool erstellt wurde, und führen Sie dann den folgenden Befehl aus, um zu prüfen, ob alle Knoten der Domain hinzugefügt wurden:

    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

    Wenn die Knoten mit der Domain verknüpft wurden, sieht die Ausgabe so aus:

    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.

    Wenn Sie die vollständige Skriptausgabe sehen möchten, entfernen Sie .*success aus dem grep-Befehl.

GKE-Pods Zugriff auf Active Directory gewähren

Sie müssen eine Firewallregel erstellen, die den Pods des GKE-Clusters den Zugriff auf Ihre Domaincontroller mithilfe der folgenden Protokolle ermöglicht:

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

Sie können die Regel anhand eines Dienstkontos anwenden, das Sie Ihren Domaincontrollern zugewiesen haben. Sie können sie auch mithilfe eines Netzwerk-Tags anwenden, wie in dieser Anleitung beschrieben. Weitere Informationen zu Active Directory-bezogenen Ports finden Sie in der Dokumentation zu Active Directory-Port- und -Protokollanforderungen und Managed Microsoft AD über Firewalls hinweg verwenden.

Wenn Sie Managed Service for Microsoft Active Directory (Managed Microsoft AD) verwenden, können Sie diesen Vorgang überspringen.

  1. Rufen Sie in Cloud Shell den Pod-IP-Adressbereich des GKE-Clusters ab:

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

  2. Erstellen Sie eine Firewallregel, um den GKE-Pods Zugriff auf Active Directory zu gewähren:

    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

    Ersetzen Sie DC-TAG durch das Netzwerk-Tag, das den VMs Ihrer Domaincontroller zugewiesen ist.

GKE für die Unterstützung der Verwendung von gMSAs konfigurieren

Wenn Sie ein gMSA in Windows Server-Knoten verwenden möchten, müssen Sie das gMSA-Objekt in Active Directory erstellen, eine entsprechende gMSA-Ressource in GKE erstellen und neu erstellten Pods ermöglichen, ihre gMSA-Anmeldedaten abzurufen.

  1. Laden Sie in Cloud Shell das gMSA-Webhook-Skript herunter und führen Sie es aus:

    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

    Das Skript fügt Ihrem GKE-Cluster das gMSA-Manifest der benutzerdefinierten Ressourcendefinition (CRD) hinzu und stellt einen Webhook bereit, der die gMSA-Spezifikationen für Pods bereitstellt. Sie können gMSA-Spezifikationen jetzt in Ihrem Cluster speichern und gMSAs für Pods und Container konfigurieren.

    Weitere Informationen zu Kubernetes und gMSAs finden Sie unter GMSA für Windows-Pods und -Container konfigurieren.

Ihr GKE-Cluster kann jetzt Windows-Anwendungen ausführen, für die ein gMSA erforderlich ist. Sie können beispielsweise eine ASP.NET-Webanwendung auf Ihren Windows Server-Knoten ausführen. Sie können die Anwendung so konfigurieren, dass Nutzer mit Windows-Authentifizierung angemeldet werden oder dass sie mit dem gMSA des Pods auf eine Remote-Netzwerkfreigabe oder eine SQL Server-Datenbank zugreifen kann.

In Active Directory einbinden

Als Nächstes erstellen Sie ein gMSA für Ihre ASP.NET-Webanwendung in Active Directory. Dann konfigurieren Sie, wie sie verwendet werden kann und von wem und fügen ihre Konfiguration zu GKE hinzu.

Anmelden und PowerShell starten

  1. Verbindung zur gmsa-dev-vm-VM herstellen.

  2. Melden Sie sich bei Windows mit einem Active Directory-Konto an, das ein gMSA erstellen darf.

    Ihr Konto muss Mitglied der Gruppe Domain Admins sein oder msDS-GroupManagedServiceAccount-Objekte erstellen können. Weitere Informationen finden Sie unter Gruppenverwaltete Dienstkonten bereitstellen.

    Wenn Sie Managed Microsoft AD verwenden, muss Ihr Konto Mitglied der Gruppe Cloud Service Managed Service Account Administrators sein. Weitere Informationen finden Sie unter Verwaltung verwalteter Dienstkonten delegieren.

  3. Geben Sie 15 ein, um das Menü zur Befehlszeile zu beenden (PowerShell).

Containerlaufzeit installieren

Windows Server 2022 erfordert eine Containerlaufzeit wie Docker Community Edition (CE), um Windows-Container zu erstellen und auszuführen. Weitere Informationen zum Installieren einer Containerlaufzeit auf Windows Server finden Sie in der Microsoft-Dokumentation unter Erste Schritte: Windows für Container vorbereiten.

Wenn Sie die Entwicklungs-VM mit dem Image windows-2019-core-for-containers erstellt haben, können Sie das folgende Verfahren überspringen, da auf dem Image Docker bereits installiert ist.

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

    Wenn die Remote Desktop-Verbindung während der Installation getrennt wird, stellen Sie die Verbindung zur VM wieder her.

  2. Warten Sie, bis der Installationsvorgang abgeschlossen ist, und geben Sie dann exit ein, um das neue PowerShell-Fenster zu schließen.

  3. Geben Sie 15 ein, um das Menü zur Befehlszeile zu beenden (PowerShell).

KDS-Root-Schlüssel erstellen

Bevor Sie ein gMSA erstellen, müssen Sie sicherstellen, dass Ihr Active Directory-Domänencontroller einen KDS-Root-Schlüssel (Key Distribution Services) hat. Active Directory verwendet den KDS-Root-Schlüssel, um Passwörter für gMSAs zu generieren.

Wenn Sie Managed Microsoft AD verwenden, können Sie das folgende Verfahren überspringen, da Managed Microsoft AD den KDS-Root-Schlüssel beim Erstellen der Domain erstellt.

  1. Prüfen Sie auf gmsa-dev-vm, ob Active Directory bereits den KDS-Root-Schlüssel enthält:

    Get-KdsRootKey

    Dieser Befehl zeigt die Schlüssel-ID an, sofern vorhanden.

  2. Wenn Sie keine Schlüssel-ID als Antwort erhalten, erstellen Sie den Schlüssel:

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

gMSA erstellen

Wenn Sie ein gMSA erstellen, müssen Sie die Namen der Computer angeben, die Zugriff auf das gMSA haben. Als bewährte Sicherheitsmaßnahme sollten Sie nur den Instanzen, auf denen Ihre Anwendung ausgeführt wird, die Berechtigung für das gMSA erteilen. Wenn Sie einen in die Domain eingebundenen Windows Server-Knotenpool erstellen, wird eine neue Active Directory-Gruppe für die Computer des Knotenpools erstellt. Der Name der Gruppe entspricht dem Namen der verwalteten Instanzgruppe (MIG), die GKE für den Knotenpool erstellt.

  1. Legen Sie in PowerShell Variablen für die Google Cloud-Projekt-ID, den Clusternamen, den Windows-Knotenpoolnamen, den gMSA-Namen und den AD-Domainnamen fest:

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

    Ersetzen Sie PROJECT-ID durch Ihre Google Cloud-Projekt-ID.

  2. Legen Sie die Clusterkonfiguration für das gcloud-Tool fest:

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

    Ersetzen Sie ZONE-NAME durch die Zone, in der Sie den GKE-Cluster bereitgestellt haben.

  3. Rufen Sie den Domainnamen der Active Directory-Gruppe ab, die für den Knotenpool erstellt wurde:

    $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. Erstellen Sie das gMSA:

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

  5. Prüfen Sie, ob das gMSA erstellt wurde:

    Get-ADServiceAccount -Identity $GmsaName

    Wenn das gMSA erstellt wurde, sieht die Ausgabe in etwa so aus:

    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 :

gMSA zu GKE hinzufügen

Wenn Sie ein gMSA in einem Kubernetes-Cluster verwenden möchten, müssen Sie in Kubernetes eine gMSA-Ressource erstellen und müssen konfigurieren, welche Namespaces und Konten es verwenden dürfen.

  1. Installieren Sie auf gmsa-dev-vm in PowerShell das git-Tool:

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

  2. Installieren Sie das kubectl-Tool:

    $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. Installieren Sie die gke-gcloud-auth-plugin-Binärdatei:

    gcloud components install gke-gcloud-auth-plugin

    Warten Sie einige Minuten, bis die Installation abgeschlossen ist.

  4. Initialisieren Sie das kubectl-Tool mit den Anmeldedaten Ihres GKE-Clusters:

    gcloud container clusters get-credentials $GkeClusterName

  5. Erstellen Sie die gMSA-Anmeldedatenspezifikation:

    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

    Der Name der Ressource GMSACredentialSpec in Kubernetes muss Kleinbuchstaben verwenden.

    Das Skript ändert die Großschreibung der Variable $GmsaName entsprechend dieser Einschränkung.

    Das Skript zeigt (wie erwartet) eine Warnmeldung an, dass das Testen des verwalteten Dienstkontos fehlgeschlagen ist. Ihre Entwicklungs-VM ist kein Mitglied der Gruppe, die dem gMSA zugewiesen ist. Daher können Sie das gMSA nicht von der VM aus testen. Die Warnmeldung verhindert nicht, dass der Befehl die gMSA-Anmeldedatenspezifikation generiert.

  6. Fügen Sie dem GKE-Cluster die gMSA-Anmeldedatenspezifikation hinzu:

    kubectl apply -f $CredSpecFile

  7. Klonen Sie das GitHub-Repository:

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

  8. Fügen Sie Ihrem Cluster die gMSA-RBAC-Objekte hinzu:

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

    Die gmsa-rbac-webapp-01.yaml erstellt ein ClusterRole-RBAC-Objekt für das gMSA und bindet dann die neue Clusterrolle an das Standarddienstkonto im Namespace default. Wenn Sie Ihre Anwendung in einem anderen Namespace bereitstellen, bearbeiten Sie die Datei gmsa-rbac-webapp-01.yaml und ändern Sie den Namespace für die Rollenbindung und das Dienstkonto.

Webanwendung bereitstellen und verwenden

Als Nächstes erstellen Sie die Webanwendung und das Container-Image, stellen das neue Container-Image in Ihrem GKE-Cluster bereit und öffnen die Webanwendung im Browser, um zu prüfen, ob die Webanwendung das gMSA verwenden kann.

ASP.NET-Webanwendung erstellen und bereitstellen

  1. Legen Sie in PowerShell auf gmsa-dev-vm Variablen für den Registry-Standort, den Registry-Namen und das Image-Tag fest:

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

    Ersetzen Sie LOCATION durch den Speicherort, an dem Sie das Artifact Registry-Repository erstellt haben.

  2. Erstellen Sie das Container-Image:

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

    Zum Erstellen von Container-Images für Windows Server 2019 legen Sie für den Parameter -f den Wert Dockerfile-WINDOWS_LTSC2019 fest.

  3. Container-Image per Push an Artifact Registry übertragen:

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

  4. Laden Sie die YAML-Datei der Anwendung herunter und aktualisieren Sie sie mit Ihrer gMSA-Konfiguration:

    $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

    Wenn Sie Windows Server 2019-Knoten in GKE erstellen, bearbeiten Sie die YAML-Datei der Anwendung und ändern Sie den Wert von cloud.google.com/gke-windows-os-version von 2022 auf 2019.

  5. Stellen Sie die Webanwendung in Ihrem GKE-Cluster bereit:

    kubectl apply -f $ApplicationYaml

Ausführung der ASP.NET-Webanwendung prüfen

Die Webanwendung wird über einen LoadBalancer-Dienst im Internet bereitgestellt. Bevor Sie die Webanwendung aufrufen können, müssen Sie warten, bis der Pod und der Dienst bereitgestellt wurden. Die Bereitstellung des Pods kann einige Minuten dauern, da die Container-Images von Windows Server Core groß sind (das Image der Webanwendung ist größer als 7 GB), und es dauert einige Zeit, bis der Knoten das Image heruntergeladen und den Container erstellt hat.

  1. Prüfen Sie den Pod-Status:

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

    Wiederholen Sie den Befehl, bis in der Ausgabe angezeigt wird, dass der Pod-Status Wird ausgeführt lautet:

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

    Wenn der Status des Pods Ausstehend bleibt und sich weder in ContainerCreating noch in Wird ausgeführt ändert, prüfen Sie das Quell-Image Ihres Windows-Knotens, um sicherzustellen, dass es Windows Server 2022 ist. Sie können auch die Tabelle Versionszuordnung verwenden, um zu sehen, wie GKE-Versionen Windows Server-Versionen zugeordnet werden. Wenn die Versionen nicht übereinstimmen, duplizieren Sie die Datei Dockerfile-WINDOWS_LTSC2022 und legen Sie das Basis-Container-Image in der neuen Datei so fest, dass es der Windows Server-Version Ihrer Knoten entspricht. Wiederholen Sie dann die Schritte zum Erstellen und Bereitstellen der ASP.NET-Webanwendung.

  2. Prüfen Sie den Status des Dienstes:

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

    Wiederholen Sie den Befehl, bis in der Ausgabe angezeigt wird, dass der Dienst eine externe IP-Adresse hat:

    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. Notieren Sie sich den Wert von external-ip in der Ausgabe. Sie benötigen diesen Wert später.

Vorabtests in der ASP.NET-Webanwendung ausführen

Der Pod wird jetzt ausgeführt und ist über einen Netzwerk-Load-Balancer vom Internet aus zugänglich. Als Nächstes führen Sie Vorabtests aus, um zu prüfen, ob der Container erfolgreich bereitgestellt wurde und über Berechtigungen zur Verwendung des gMSA verfügt.

  1. Rufen Sie in einem Browser http://EXTERNAL-IP auf, um die gMSA-Testwebanwendung aufzurufen.

    Ersetzen Sie EXTERNAL-IP durch die IP-Adresse, die Sie im vorherigen Verfahren abgerufen haben.

  2. Scrollen Sie zum Abschnitt Preflight-Prüfungen und klicken Sie auf die Schaltfläche Preflight-Prüfungen ausführen, um zu prüfen, ob alle Tests bestanden wurden.

    Wenn die Tests erfolgreich waren, sieht die Ausgabe so aus:

    [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. Scrollen Sie zum Abschnitt Containerinformationen und klicken Sie dann auf die Schaltfläche Skript ausführen. Vergewissern Sie sich, dass Sie Informationen über den Container und den Knoten sehen und dass kein Fehler angezeigt wird.

gMSA in Windows-Containern verwenden

Sie können jetzt prüfen, ob die gMSA-Einrichtung ordnungsgemäß funktioniert, indem Sie mehrere Tests in der Webanwendung ausführen. Jeder der Tests verwendet das gMSA für einen anderen Zweck. Wenn alle Tests erfolgreich sind, haben Sie das gMSA richtig konfiguriert.

gMSA-Containerkonfiguration validieren

  • Scrollen Sie zum Abschnitt Domainkonnektivität, geben Sie den Namen Ihres gMSA (WebApp-01) in das Feld Kontoname ein und klicken Sie dann auf Skript ausführen. Warten Sie einige Sekunden, bis die Tests abgeschlossen sind.

    Die Ausgabe sieht etwa so aus:

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

    Das Skript verwendet zwei PowerShell-Cmdlets, um den Zugriff auf das gMSA zu testen:

    • Get-ADServiceAccount: Dieses Cmdlet ruft Informationen zu einem gMSA ab. Wenn dieses Cmdlet erfolgreich ausgeführt wird, läuft der Container mit einem gültigen gMSA.
    • Test-ADServiceAccount: Dieses Cmdlet testet, ob es die gMSA-Anmeldedaten abrufen kann. Wenn das Cmdlet erfolgreich ausgeführt wird, wird der Container auf einem Windows Server-Knoten ausgeführt, der Zugriff auf die gMSA-Anmeldedaten hat.

Nutzer mit Windows-Authentifizierung anmelden

  1. Klicken Sie in der oberen Navigationsleiste der Seite auf Anmelden.
  2. Wenn Sie zur Eingabe Ihrer Anmeldedaten aufgefordert werden, geben Sie Ihren Domainnamen und das Passwort ein.

  3. Wenn Sie die Seite Sicher mit Ihren Kontoinformationen sehen und nicht zur Eingabe von Anmeldedaten aufgefordert werden, hat Ihr Browser Sie automatisch mit Ihrer aktuellen Identität angemeldet.

    Nach der Authentifizierung wird die Seite Sicher angezeigt. Sie müssen die folgenden drei Abschnitte sehen:

    • Nutzerinformationen: Zeigt Ihren Nutzernamen und den verwendeten Authentifizierungstyp an.
    • Gruppen: Hier wird die Liste der Gruppen angezeigt, in denen Sie Mitglied sind. Die Gruppennamen in der Liste werden aus Active Directory abgerufen.
    • Nutzeranforderungen: Zeigt die Liste der Anforderungen für den Nutzer an, die von Active Directory während der Anmeldung bereitgestellt werden. Die Anforderungen für die Gruppenmitgliedschaft zeigen die Active Directory-Gruppen-SID und nicht die Namen an.

Zusätzlich zur Unterstützung der integrierten Windows-Authentifizierung kann die ASP.NET-Webanwendung ihr gMSA für die Authentifizierung beim Aufrufen von Remote-Servern verwenden. Mit dem gMSA können die Webanwendung und jede andere im Windows-Container ausgeführte Anwendung auf Ressourcen im Netzwerk zugreifen, die eine Windows-Authentifizierung erfordern, z. B. SQL Server-Instanzen und SMB-basierte Netzwerkfreigaben.

Fehlerbehebung

Wenn Sie während der Einrichtung oder beim Testen der Webanwendung Fehlermeldungen erhalten, lesen Sie die folgenden Seiten zur Fehlerbehebung:

Weitere Überlegungen zu Produktionsanwendungen

Die Anweisungen, die Sie befolgt haben, wurden erstellt, um einen optimalen Pfad für die Zwecke der Anleitung bereitzustellen. In einer Produktionsumgebung können Sie Änderungen an einigen Verfahren vornehmen, um das Ergebnis robuster zu machen, wie in den folgenden Abschnitten beschrieben.

Überlegungen zu Windows Server-Knotenpools

Wenn Sie Ihre eigene Anwendung bereitstellen möchten, die ein gMSA verwendet, und die Anwendung Clientsitzungen unterstützt, empfehlen wir, dass Sie mindestens zwei Knoten im Knotenpool erstellen. Wenn Sie mehrere Knoten haben, können Sie mit dem Out-of-Process-Sitzungsspeicher prüfen, ob Ihre Anwendung verteilte Sitzungen ordnungsgemäß verarbeiten kann.

In dieser Anleitung erstellen Sie einen einzelnen Windows Server-Knotenpool zum Hosten Ihrer Anwendungen. Es gibt jedoch Situationen, in denen Sie mehrere Windows Server-Knotenpools in Ihrem Cluster erstellen möchten, z. B. einen Knotenpool mit nichtflüchtigen HDD-Speichern und einen anderen Knotenpool mit nichtflüchtigen SSD-Speichern. Wenn Sie Ihre Anwendung in mehreren Knotenpools bereitstellen müssen, geben Sie beim Erstellen des gMSA mit dem Cmdlet New-ADServiceAccount ein Array von Active Directory-Gruppenobjekten für den Parameter PrincipalsAllowedToRetrieveManagedPassword an.

Überlegungen zum gMSA und zum Service Principal Name (SPN)

Wenn Ihre Anwendung erfordert, dass Sie Nutzer mithilfe von Kerberos authentifizieren, um beispielsweise die Identitätsdelegation zu unterstützen, müssen Sie über ein benutzerdefiniertes DNS auf Ihre Anwendung zugreifen und das gMSA mit einem Service Principal Name (SPN) konfigurieren. Wenn Ihr Load-Balancer beispielsweise die Anwendung über https://my-web-app/ in GKE verfügbar macht, müssen Sie den SPN HTTP/my-web-app auf eine der folgenden Arten erstellen:

  • Erstellen Sie ein neues gMSA mit den erforderlichen SPNs. Beispiel:

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

  • Rufen Sie für ein vorhandenes gMSA Set-ADServiceAccount auf, um dem gMSA die erforderlichen SPNs hinzuzufügen. Beispiel:

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

Abhängig von Ihrer DNS-Konfiguration müssen Sie möglicherweise auch einen SPN für HTTP/www.my-web-app und HTTP/www.my-web-app.$AdDomain erstellen.

Bei Nicht-HTTP-Protokollen, z. B. bei einem mit TCP-Bindung und Windows-Authentifizierung konfigurierten WCF-Dienst, müssen Sie möglicherweise andere Typen von SPNs erstellen, z. B. einen HOST/-SPN.

IIS-Anwendungspool-Identität auswählen

ASP.NET-Webanwendungen werden in Windows auf dem IIS-Webserver ausgeführt. In IIS konfigurieren Sie Gruppen von Webanwendungen, die denselben Prozess verwenden. Diese Gruppe wird als Anwendungspool bezeichnet. Jeder Anwendungspool wird in einem dedizierten Prozess namens w3wp gehostet. IIS-Anwendungspools bieten eine Prozesskonfiguration, z. B. ob es sich um einen 32-Bit- oder 64-Bit-Prozess handelt, und sie liefern die Identität des Prozesses. Wenn Sie eine Webanwendung in einem Windows-Container ausführen, legen Sie die Prozessidentität des Anwendungspools so fest, dass das integrierte Netzwerkdienstkonto verwendet wird.

Die von IIS unterstützten lokalen Konten für die Anwendungspool-Identität sind in Windows-Containern nicht erforderlich. Die Anwendungspool-Identitätskonten wurden von IIS erstellt, um eine lokale Sicherheitsgrenze zu erzwingen, wenn mehrere Webanwendungen auf derselben IIS-Instanz ausgeführt werden. Bei Windows-Containern, bei denen jede Webanwendung in einem separaten Container gehostet wird, muss keine Sicherheitsgrenze innerhalb des Containers erstellt werden, da der Container selbst die Sicherheitsgrenze bereitstellt.

Die Anwendungspool-Identität ist so konfiguriert, dass sie das Netzwerkdienstkonto verwendet. Wenn die Anwendung eine Anfrage an eine externe Ressource sendet, die eine Authentifizierung erfordert, authentifiziert sich die Anwendung mithilfe des für den Windows-Container konfigurierten gMSA.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Einzelne Ressourcen entfernen

Wenn Sie Ihr Google Cloud-Projekt beibehalten, aber die Google Cloud-Ressourcen löschen möchten, die Sie für diese Anleitung erstellt haben, können Sie die Ressourcen einzeln entfernen.

Active Directory-Änderungen zurücksetzen

  1. Stellen Sie eine Verbindung zur Entwicklungs-VM her und melden Sie sich als ein Nutzer an, der Administratorzugriff auf Ihre Active Directory-Domain hat.

  2. Wenn PowerShell noch nicht geöffnet ist, öffnen Sie es auf der VM gmsa-dev-vm:

    PowerShell

  3. Löschen Sie das gMSA:

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

Cloud-Ressourcen löschen

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. Initialisieren Sie die gcloud-Umgebung:

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

    Ersetzen Sie Folgendes:

    • PROJECT-ID: Ihre Google Cloud-Projekt-ID.
    • ZONE-NAME: Die Zone, in der Sie den GKE-Cluster und die Entwicklungs-VM bereitgestellt haben.
    • LOCATION: Die Region, in der Sie das Artifact Registry-Repository bereitgestellt haben.

  3. Löschen Sie die Entwicklungs-VM:

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

  4. Löschen Sie das Dienstkonto:

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

  5. Löschen Sie den GKE-Cluster:

    gcloud container clusters delete cluster-1 --quiet

  6. Wenn Sie eine Firewallregel für Ihre Active Directory-Controller erstellt haben, löschen Sie sie:

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

  7. Artifact Registry-Docker-Repository löschen:

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

Führen Sie zum Bereinigen die Schritte unter Active Directory für VMs für den automatischen Domainbeitritt konfigurieren aus.

Nächste Schritte