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. # Verwendung von gMSA für EC2-Linux-Container in Amazon ECS Amazon ECS unterstützt die Active-Directory-Authentifizierung für Linux-Container in EC2 über ein spezielles Service-Konto namens *group Managed Service Account* (gMSA). Linux-basierte Netzwerkanwendungen wie .NET-Core-Anwendungen können Active Directory verwenden, um die Authentifizierung und Autorisierung zwischen Benutzern und Services zu verwalten. Sie können dieses Feature nutzen, indem Sie Anwendungen entwickeln, die mit Active Directory integriert sind und auf Domain-verbundenen Servern laufen. Da Linux-Container jedoch nicht mit einer Domain verbunden werden können, müssen Sie einen Linux-Container für die Ausführung mit gMSA konfigurieren. Ein Linux-Container, der mit gMSA ausgeführt wird, stützt sich auf den `credentials-fetcher`-Daemon, der auf der Amazon-EC2-Host-Instance des Containers läuft. Das heißt, der Daemon ruft die gMSA-Anmeldeinformationen vom Active Directory-Domain-Controller ab und überträgt diese Anmeldeinformationen an die Container-Instance. Weitere Informationen zu Servicekonten finden Sie unter [gMSAs für Windows-Container erstellen](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts) auf der Microsoft-Learn-Website. ## Überlegungen Beachten Sie Folgendes, bevor Sie gMSA für Linux-Container verwenden: + Wenn Ihre Container auf EC2 ausgeführt werden, können Sie sie gMSA für Windows-Container und Linux-Container verwenden. Informationen zur Verwendung von gMSA für Linux-Container in Fargate finden Sie unter [Verwendung von gMSA für Linux-Container in Fargate](fargate-linux-gmsa.md). + Möglicherweise benötigen Sie einen Windows-Computer, der mit der Domain verbunden ist, um die Voraussetzungen zu erfüllen. Beispielsweise benötigen Sie möglicherweise einen Windows-Computer, welcher mit der Domain verbunden ist, um die gMSA in Active Directory mit PowerShell zu erstellen. Die RSAT Active PowerShell Director-Tools sind nur für verfügbarWindows. Weitere Informationen finden Sie unter [Installieren der Active-Directory-Verwaltungstools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html). + Sie haben zwischen **domainlose gMSA** und **Hinzufügen jeder Instance zu einer einzelnen Domain** gewählt. Durch die Verwendung von domainlosen gMSA ist die Container-Instance nicht mit der Domain verbunden, andere Anwendungen auf der Instance können die Anmeldeinformationen nicht verwenden, um auf die Domain zuzugreifen, und Aufgaben, die verschiedenen Domains angehören, können auf derselben Instance ausgeführt werden. Wählen Sie dann den Datenspeicher für CredSpec und optional für die Active-Directory-Benutzeranmeldeinformationen für domainlose gMSA. Amazon ECS verwendet eine Spezifikationsdatei für Active-Directory-Anmeldeinformationen (CredSpec). Diese Datei enthält die gMSA-Metadaten, die verwendet werden, um den gMSA-Kontokontext an den Container weiterzuleiten. Sie generieren die CredSpec-Datei und speichern sie dann in einer der CredSpec-Speicheroptionen in der folgenden Tabelle, die für das Betriebssystem der Container-Instances spezifisch sind. Um die domainlose Methode zu verwenden, kann ein optionaler Abschnitt in der CredSpec-Datei Anmeldeinformationen in einer der *domainless user credentials*-Speicheroptionen in der folgenden Tabelle angeben, die für das Betriebssystem der Container-Instances spezifisch sind. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/linux-gmsa.html) ## Voraussetzungen Bevor Sie das gMSA-Feature für Linux-Container mit Amazon ECS verwenden, müssen Sie folgende Schritte ausführen: + Sie richten eine Active-Directory-Domain mit den Ressourcen ein, auf die Ihre Container zugreifen sollen. Amazon ECS unterstützt die folgenden Einrichtungen: + Ein Directory Service Active Directory. Directory Service ist ein AWS verwaltetes Active Directory, das auf Amazon EC2 gehostet wird. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) im *AWS Directory Service Administratorhandbuch*. + Ein On-Premises-Active-Directory. Sie müssen sicherstellen, dass die Container-Instance von Amazon ECS Linux der Domain beitreten kann. Weitere Informationen finden Sie unter [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html). + Sie haben ein bestehendes gMSA-Konto im Active Directory. Weitere Informationen finden Sie unter [Verwendung von gMSA für EC2-Linux-Container in Amazon ECS](#linux-gmsa). + Sie haben den `credentials-fetcher`-Daemon auf einer Container-Instance von Amazon ECS Linux installiert und führen ihn dort aus. Sie haben dem `credentials-fetcher`-Daemon auch einen ersten Satz von Anmeldeinformationen hinzugefügt, um sich mit dem Active Directory zu authentifizieren. **Anmerkung** Der `credentials-fetcher`-Daemon ist nur für Amazon Linux 2023 und Fedora 37 und höher verfügbar. Der Daemon ist für Amazon Linux 2 nicht verfügbar. Weitere Informationen finden Sie unter [aws/credentials](https://github.com/aws/credentials-fetcher) fetcher on. GitHub + Sie richten die Anmeldeinformationen für den `credentials-fetcher`-Daemon ein, um sich mit dem Active Directory zu authentifizieren. Die Anmeldeinformationen müssen Mitglied der Active-Directory-Sicherheitsgruppe sein, die Zugriff auf das gMSA-Konto hat. Es gibt mehrere Optionen in [Entscheiden Sie, ob Sie die Instances mit der Domain verbinden oder domainlose gMSA verwenden möchten.](#linux-gmsa-initial-creds). + Sie haben die erforderlichen IAM-Berechtigungen hinzugefügt. Welche Berechtigungen erforderlich sind, hängt von den Methoden ab, die Sie für die anfänglichen Anmeldeinformationen und für die Speicherung der Anmeldeinformation wählen: + Wenn Sie *Domainless gMSA* für anfängliche Anmeldeinformationen verwenden, sind IAM-Berechtigungen für für die Aufgabenausführungsrolle erforderlich. AWS Secrets Manager + Wenn Sie die Spezifikation der Anmeldeinformationen im SSM Parameter Store speichern, sind IAM-Berechtigungen für den Amazon EC2 Systems Manager Parameter Store für die Rolle der Aufgabenausführung erforderlich. + Wenn Sie die Spezifikation der Anmeldeinformationen in Amazon S3 speichern, sind IAM-Berechtigungen für Amazon Simple Storage Service für die Rolle der Aufgabenausführung erforderlich. ## Einrichten von gMSA-fähigen Linux-Containern unter Amazon ECS **Die Infrastruktur vorbereiten** Bei den folgenden Schritten handelt es sich um Überlegungen und Einstellungen, die einmal durchgeführt werden müssen. Nachdem Sie diese Schritte ausgeführt haben, können Sie die Erstellung von Container-Instances automatisieren, um diese Konfiguration wiederzuverwenden. Entscheiden Sie, wie die anfänglichen Anmeldeinformationen bereitgestellt werden, und konfigurieren Sie die EC2-Benutzerdaten in einer wiederverwendbaren EC2-Startvorlage, um den `credentials-fetcher`-Daemon zu installieren. 1. **Entscheiden Sie, ob Sie die Instances mit der Domain verbinden oder domainlose gMSA verwenden möchten.** + **EC2-Instances mit der Active Directory-Domain verbinden** + **Die Instances anhand von Benutzerdaten hinzufügen** Fügen Sie die Schritte zum Verbinden der Active-Directory-Domain mit Ihren EC2-Benutzerdaten in eine EC2-Startvorlage ein. Mehrere Gruppen von Amazon EC2 Auto Scaling können dieselbe Startvorlage verwenden. Sie können diese Schritte in den Fedora Docs zum [Beitreten zu einem Active Directory oder einer FreeIPA-Domain](https://docs.fedoraproject.org/en-US/quick-docs/join-active-directory-freeipa/) verwenden. + **Erstellen Sie einen Active-Directory-Benutzer für domainlose gMSA** *Der `credentials-fetcher`-Daemon verfügt über ein Feature, die als domainlose gMSA bezeichnet wird.* Für dieses Feature ist eine Domain erforderlich, die EC2-Instance muss jedoch nicht mit der Domain verbunden werden. Durch die Verwendung von domainlosen gMSA ist die Container-Instance nicht mit der Domain verbunden, andere Anwendungen auf der Instance können die Anmeldeinformationen nicht verwenden, um auf die Domain zuzugreifen, und Aufgaben, die verschiedenen Domains angehören, können auf derselben Instance ausgeführt werden. Stattdessen geben Sie den Namen eines Secrets in AWS Secrets Manager in der CredSpec-Datei an. Das Secret muss einen Benutzernamen, ein Passwort und die Domain enthalten, bei der die Anmeldung erfolgen soll. Dieses Feature wird unterstützt und kann mit Linux- und Windows-Containern verwendet werden. Dieses Feature ähnelt dem *gMSA support for non-domain-joined container hosts*-Feature. Weitere Informationen zum Windows-Feature finden Sie unter [gMSA-Architektur und -Verbesserungen](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#gmsa-architecture-and-improvements) auf der Microsoft-Learn-Website. 1. Erstellen Sie einen Benutzer in Ihrer Active-Directory-Domain. Der Benutzer in Active Directory muss berechtigt sein, auf die gMSA-Servicekonten zuzugreifen, die Sie für die Aufgaben verwenden. 1. Erstellen Sie ein Geheimnis in AWS Secrets Manager, nachdem Sie den Benutzer in Active Directory erstellt haben. Weitere Informationen finden Sie unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). 1. Geben Sie den Benutzernamen, das Passwort und die Domain des Benutzers in JSON-Schlüssel-Wert-Paare mit den Bezeichnungen `username`, `password` bzw. `domainName`, ein. ``` {"username":"username","password":"passw0rd", "domainName":"example.com"} ``` 1. Fügen Sie der CredSpec-Datei die Konfiguration für das Servicekonto hinzu. Der zusätzliche `HostAccountConfig` enthält den Amazon-Ressourcennamen (ARN) des Secrets in Secrets Manager. Auf Windows muss der `PluginGUID` mit der GUID im folgenden Beispielausschnitt übereinstimmen. Auf Linux wird der `PluginGUID` ignoriert. Ersetzen Sie `MySecret` zum Beispiel durch den Amazon-Ressourcennamen (ARN) Ihres Secrets. ``` "ActiveDirectoryConfig": { "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } } ``` 1. Für das Feature *domainlose gMSA* sind zusätzliche Berechtigungen in der Aufgabenausführungsrolle erforderlich. Folgen Sie dem Schritt [(Optional) domainloses gMSA-Secret](#linux-gmsa-domainless-secret). 1. **Instances und installieren Sie den `credentials-fetcher`-Daemon konfigurieren** Sie können den `credentials-fetcher`-Daemon mit einem Benutzerdatenskript in Ihrer EC2-Startvorlage installieren. Die folgenden Beispiele veranschaulichen zwei Arten von Benutzerdaten `cloud-config` YAML oder bash-Skript. Diese Beispiele gelten für Amazon Linux 2023 (AL2023). Ersetzen Sie `MyCluster` durch den Namen des Amazon-ECS-Clusters, mit dem diese Instances verbunden werden sollen. + **`cloud-config` YAML** ``` Content-Type: text/cloud-config package_reboot_if_required: true packages: # prerequisites - dotnet - realmd - oddjob - oddjob-mkhomedir - sssd - adcli - krb5-workstation - samba-common-tools # https://github.com/aws/credentials-fetcher gMSA credentials management for containers - credentials-fetcher write_files: # configure the ECS Agent to join your cluster. # replace MyCluster with the name of your cluster. - path: /etc/ecs/ecs.config owner: root:root permissions: '0644' content: | ECS_CLUSTER=MyCluster ECS_GMSA_SUPPORTED=true runcmd: # start the credentials-fetcher daemon and if it succeeded, make it start after every reboot - "systemctl start credentials-fetcher" - "systemctl is-active credentials-fetcher && systemctl enable credentials-fetcher" ``` + **bash-Skript** Wenn Sie sich mit bash-Skripten besser auskennen und mehrere Variablen in `/etc/ecs/ecs.config` zu schreiben haben, verwenden Sie das folgende `heredoc`-Format. Bei Verwendung dieses Formats wird alles zwischen den Zeilen **cat** und `EOF` in die Konfigurationsdatei geschrieben. ``` #!/usr/bin/env bash set -euxo pipefail # prerequisites timeout 30 dnf install -y dotnet realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation samba-common-tools # install https://github.com/aws/credentials-fetcher gMSA credentials management for containers timeout 30 dnf install -y credentials-fetcher # start credentials-fetcher systemctl start credentials-fetcher systemctl is-active credentials-fetcher && systemctl enable credentials-fetcher cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_GMSA_SUPPORTED=true EOF ``` Es gibt optionale Konfigurationsvariablen für den `credentials-fetcher`-Daemon, die Sie in `/etc/ecs/ecs.config` einrichten können. Wir empfehlen, dass Sie die Variablen in den Benutzerdaten im YAML-Block oder `heredoc` ähnlich wie in den vorherigen Beispielen festlegen. Dadurch werden Probleme mit der teilweisen Konfiguration vermieden, die beim mehrfachen Bearbeiten einer Datei auftreten können. Weitere Informationen zur Konfiguration des ECS-Agenten finden Sie unter [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md#environment-variables) unter GitHub. + Optional können Sie die Variable `CREDENTIALS_FETCHER_HOST` verwenden, wenn Sie die `credentials-fetcher`-Daemon-Konfiguration ändern, um den Socket an einen anderen Ort zu verschieben. **Einrichten von Berechtigungen und Secrets** Führen Sie die folgenden Schritte einmal für jede Anwendung und jede Aufgabendefinition aus. Wir empfehlen Ihnen, die bewährte Methode anzuwenden, die geringste Berechtigung zu gewähren und die in der Richtlinie verwendeten Berechtigungen einzuschränken. Auf diese Weise kann jede Aufgabe nur die Secrets lesen, die sie benötigt. 1. **(Optional) domainloses gMSA-Secret** Wenn Sie die domainlose Methode verwenden, bei der die Instance nicht mit der Domain verknüpft ist, gehen Sie wie folgt vor. Sie müssen die folgenden Berechtigungen als eingebundene Richtlinie zu der IAM-Rolle für die Aufgabenausführung hinzufügen. Dadurch erhält der `credentials-fetcher`-Daemon Zugriff auf das Secrets-Manager-Secret. Ersetzen Sie das Beispiel-`MySecret` durch den Amazon-Ressourcenname (ARN) Ihres Secrets in der `Resource`-Liste. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-AbCdEf" } ] } ``` ------ **Anmerkung** Wenn Sie Ihren eigenen KMS-Schlüssel verwenden, um Ihr Geheimnis zu verschlüsseln, müssen Sie dieser Rolle die erforderlichen Berechtigungen hinzufügen und diese Rolle der AWS KMS Schlüsselrichtlinie hinzufügen. 1. **Entscheiden Sie, ob Sie SSM Parameter Store oder S3 zum Speichern von CredSpec verwenden** Amazon ECS unterstützt die folgenden Möglichkeiten, um auf den Dateipfad im `credentialSpecs`-Feld der Aufgabendefinition zu verweisen. Wenn Sie die Instances mit einer einzigen Domain verbinden, verwenden Sie das Präfix `credentialspec:` am Anfang des ARN in der Zeichenfolge. Wenn Sie domainlose gMSA verwenden, verwenden Sie `credentialspecdomainless:`. Weitere Informationen zu CredSpecfinden Sie unter [Anmeldeinformationsspezifikationsdatei](#linux-gmsa-credentialspec). + **Amazon S3 Bucket** Fügen Sie die Anmeldeinformationsspezifikation zu einem Amazon-S3-Bucket hinzu. Dann verweisen Sie auf den Amazon-Ressourcennamen (ARN) des Amazon-S3-Buckets im `credentialSpecs`-Feld der Aufgabendefinition. ``` { "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:s3:::${BucketName}/${ObjectName}" ], ... } ], ... } ``` Um Ihren Aufgaben den Zugriff auf den S3-Bucket zu ermöglichen, fügen Sie die folgenden Berechtigungen als eingebundene Richtlinie zur IAM-Rolle für die Aufgabenausführung von Amazon ECS hinzu. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/{object}" ] } ] } ``` ------ + **SSM-Parameterspeicher-Parameter** Fügen Sie die Anmeldeinformationsspezifikation zu einem SSM-Parameter-Store-Parameter hinzu. Dann verweisen Sie auf den Amazon-Ressourcennamen (ARN) des SSM-Parameter-Store-Parameters im `credentialSpecs`-Feld der Aufgabendefinition. ``` { "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:ssm:aws-region:111122223333:parameter/parameter_name" ], ... } ], ... } ``` Um Ihren Aufgaben Zugriff auf den Parameter des SSM Parameter Store zu geben, fügen Sie die folgenden Berechtigungen als eingebundene Richtlinie zur Amazon-ECS-IAM-Rolle für die Aufgabenausführung hinzu. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:GetParameters" ], "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/my-parameter" } ] } ``` ------ ## Anmeldeinformationsspezifikationsdatei Amazon ECS verwendet eine Spezifikationsdatei für Active-Directory-Anmeldeinformationen (*CredSpec*). Diese Datei enthält die gMSA-Metadaten, die verwendet werden, um den gMSA-Kontokontext an den Linux-Container weiterzuleiten. Sie erstellen CredSpec und verweisen darauf in dem `credentialSpecs`-Feld in Ihrer Aufgabendefinition. Die CredSpec-Datei enthält keine Secrets. Im Folgenden sehen Sie ein Beispiel für eine CredSpec-Datei. ``` { "CmsPlugins": [ "ActiveDirectory" ], "DomainJoinConfig": { "Sid": "S-1-5-21-2554468230-2647958158-2204241789", "MachineAccountName": "WebApp01", "Guid": "8665abd4-e947-4dd0-9a51-f8254943c90b", "DnsTreeName": "example.com", "DnsName": "example.com", "NetBiosName": "example" }, "ActiveDirectoryConfig": { "GroupManagedServiceAccounts": [ { "Name": "WebApp01", "Scope": "example.com" } ], "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } } } } ``` **Erstellen einer CredSpec** Sie erstellen eine CredSpec indem Sie das Modul CredSpec PowerShell auf einem Windows-Computer verwenden, der mit der Domain verbunden ist. Folgen Sie den Schritten unter [Anmeldeinformationsspezifikation erstellen](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#create-a-credential-spec) auf der Microsoft-Learn-Website.