Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

gMSA für Windows-Pods und Container konfigurieren

Was ist ein gMSA-Konto

Windows-based Anwendungen wie .NET-Anwendungen verwenden häufig Active Directory als Identitätsanbieter, authorization/authentication wobei die Bereitstellung über das NTLM- oder Kerberos-Protokoll erfolgt.

Ein Anwendungsserver für den Austausch von Kerberos-Tickets mit Active Directory muss in eine Domäne eingebunden sein. Windows-Container unterstützen keine Domänenbeitritte und wären daher wenig sinnvoll, da es sich bei Containern um kurzlebige Ressourcen handelt, die den Active Directory-RID-Pool belasten.

Administratoren können jedoch gMSA Active Directory-Konten nutzen, um eine Windows-Authentifizierung für Ressourcen wie Windows-Container, NLB und Serverfarmen auszuhandeln.

Windows-Container und GMSA-Anwendungsfall

Anwendungen, die die Windows-Authentifizierung nutzen und als Windows-Container ausgeführt werden, profitieren von gMSA, da der Windows Node verwendet wird, um das Kerberos-Ticket im Namen des Containers auszutauschen. Für die Einrichtung des Windows-Worker-Knotens zur Unterstützung der gMSA-Integration stehen zwei Optionen zur Verfügung:

1 — Windows-Worker-Knoten Domain-joined

In diesem Setup ist der Windows-Worker-Knoten in der Active Directory-Domäne domänengebunden, und das AD-Computerkonto der Windows-Worker-Knoten wird verwendet, um sich bei Active Directory zu authentifizieren und die gMSA-Identität abzurufen, die mit dem Pod verwendet werden soll.

Beim domänengebundenen Ansatz können Sie Ihre Windows-Worker-Knoten mithilfe vorhandener Active Directory-GPOs problemlos verwalten und absichern. Dies verursacht jedoch zusätzlichen Betriebsaufwand und Verzögerungen beim Beitritt von Windows-Worker-Knoten zum Kubernetes-Cluster, da zusätzliche Neustarts beim Knotenstart und die Active Directory-Garagenreinigung erforderlich sind, nachdem der Kubernetes-Cluster die Knoten beendet hat.

Im folgenden Blogbeitrag erfahren Sie Schritt für Schritt, wie Sie den Windows-Worker-Node-Ansatz implementieren können: Domain-joined

Windows-Authentifizierung auf Amazon EKS-Windows-Pods

2 — Domänenlose Windows-Worker-Knoten

In diesem Setup gehört der Windows-Worker-Knoten nicht zur Active Directory-Domäne, und eine „portable“ Identität (user/password) wird verwendet, um sich bei Active Directory zu authentifizieren und die gMSA-Identität abzurufen, die mit dem Pod verwendet werden soll.

Die portable Identität ist ein Active Directory-Benutzer; die Identität (user/password) ist in AWS Secrets Manager oder AWS System Manager Parameter Store gespeichert, und ein AWS-developed Plugin namens ccg_plugin wird verwendet, um diese Identität aus AWS Secrets Manager oder AWS System Manager Parameter Store abzurufen und an containerd zu übergeben, um die gMSA-Identität abzurufen und sie für den Pod verfügbar zu machen.

Bei diesem domänenlosen Ansatz können Sie davon profitieren, dass beim Start des Windows-Worker-Knotens keine Active Directory-Interaktion stattfindet, wenn Sie gMSA verwenden, und der Betriebsaufwand für Active Directory-Administratoren reduziert wird.

Im folgenden Blogbeitrag erfahren Sie Schritt für Schritt, wie Sie den Ansatz für domänenlose Windows-Worker-Knoten implementieren können:

Domänenlose Windows-Authentifizierung für Amazon EKS-Windows-Pods

Wichtiger Hinweis

Obwohl der Pod ein gMSA-Konto verwenden kann, ist es notwendig, auch die Anwendung oder den Dienst entsprechend einzurichten, um die Windows-Authentifizierung zu unterstützen. Um beispielsweise Microsoft IIS für die Unterstützung der Windows-Authentifizierung einzurichten, sollten Sie ihn über Dockerfile vorbereiten:

RUN Install-WindowsFeature -Name Web-Windows-Auth -IncludeAllSubFeature
RUN Import-Module WebAdministration; Set-ItemProperty 'IIS:\AppPools\SiteName' -name processModel.identityType -value 2
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/anonymousAuthentication' -Name Enabled -Value False -PSPath 'IIS:\' -Location 'SiteName'
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name Enabled -Value True -PSPath 'IIS:\' -Location 'SiteName'