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.

Konfigurieren Sie gMSA für Windows-Pods und Container

Was ist ein gMSA-Konto

Windows-based Anwendungen wie .NET-Anwendungen verwenden häufig Active Directory als Identitätsanbieter und bieten dabei das NTLM- oder authorization/authentication Kerberos-Protokoll an.

Ein Anwendungsserver für den Austausch von Kerberos-Tickets mit Active Directory muss einer Domäne angehören. Windows-Container unterstützen keine Domänenbeitritte und wären daher wenig sinnvoll, da Container kurzlebige Ressourcen sind, 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.

Anwendungsfall: Windows-Container und gMSA

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. Es stehen zwei Optionen zur Verfügung, um den Windows-Worker-Knoten so einzurichten, dass er die gMSA-Integration unterstützt:

1 — Windows-Worker-Knoten Domain-joined

In diesem Setup ist der Windows-Worker-Knoten in die Active Directory-Domäne eingebunden, 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änenverbundenen Ansatz können Sie Ihre Windows-Worker-Knoten einfach mithilfe vorhandener Active Directory-GPOs verwalten und absichern. Dies verursacht jedoch zusätzlichen Betriebsaufwand und Verzögerungen beim Beitritt von Windows-Worker-Knoten im Kubernetes-Cluster, da zusätzliche Neustarts während des Knotenstarts und der Active Directory-Garagenreinigung erforderlich sind, nachdem der Kubernetes-Cluster Knoten beendet hat.

Im folgenden Blogbeitrag finden Sie eine detaillierte schrittweise Anleitung zur Implementierung des Windows-Worker-Node-Ansatzes: Domain-joined

Windows-Authentifizierung auf Amazon EKS-Windows-Pods

2 — Domänenlose Windows-Worker-Knoten

In diesem Setup ist der Windows-Worker-Knoten nicht Teil der Active Directory-Domäne, und eine „portable“ Identität (user/password) wird verwendet, um sich gegenüber 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) wird 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 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 bei Verwendung von gMSA keine Active Directory-Interaktion stattfindet und der Betriebsaufwand für Active Directory-Administratoren reduziert wird.

Im folgenden Blogbeitrag finden Sie eine detaillierte schrittweise Anleitung zur Implementierung des domänenlosen Windows-Worker Node-Ansatzes:

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

Wichtiger Hinweis

Obwohl der Pod ein gMSA-Konto verwenden kann, muss auch die Anwendung oder der Dienst entsprechend eingerichtet werden, um die Windows-Authentifizierung zu unterstützen. Um beispielsweise Microsoft IIS so einzurichten, dass die Windows-Authentifizierung unterstützt wird, sollten Sie es ü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'