Wird gMSA für Linux Container auf Fargate verwendet

Amazon ECS unterstützt die Active Directory-Authentifizierung für Linux-Container auf Fargate über ein spezielles Dienstkonto, das als Group Managed Service Account (gMSA) bezeichnet wird.

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.

Überlegungen

Beachten Sie Folgendes, bevor Sie es gMSA für Linux Container auf Fargate verwenden:

• Sie müssen die Plattformversion 1.4 oder höher ausführen.

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

• Sie müssen Domainless gMSA verwenden.

  Amazon ECS verwendet eine Active Directory-Anmeldeinformationsspezifikationsdatei (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 einem Amazon S3 S3-Bucket.

• Eine Aufgabe kann nur ein Active Directory unterstützen.

Voraussetzungen

Bevor Sie die Funktion gMSA für Linux-Container mit Amazon verwendenECS, stellen Sie sicher, dass Sie die folgenden 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 Setups:

  • Ein AWS Directory Service Active Directory. AWS Directory Service ist ein AWS verwaltetes Active Directory, das auf Amazon gehostet wirdEC2. Weitere Informationen finden Sie unter Erste Schritte mit AWS Managed Microsoft AD im AWS Directory Service Administratorhandbuch.

  • Ein On-Premises-Active-Directory. Sie müssen sicherstellen, dass die Amazon ECS Linux-Container-Instance der Domain beitreten kann. Weitere Informationen finden Sie unter AWS Direct Connect.

• Sie haben ein bestehendes gMSA Konto im Active Directory und einen Benutzer, der berechtigt ist, auf das gMSA Dienstkonto zuzugreifen. Weitere Informationen finden Sie unter Erstellen Sie einen Active-Directory-Benutzer für domainlose gMSA.

• Sie haben einen Amazon S3 S3-Bucket. Weitere Informationen finden Sie unter Bucket erstellen im Amazon S3 S3-Benutzerhandbuch.

Einrichtung von gMSA -fähigen Linux Containern bei Amazon ECS

Die Infrastruktur vorbereiten

Bei den folgenden Schritten handelt es sich um Überlegungen und Einstellungen, die einmal durchgeführt werden müssen.

• Erstellen Sie einen Active-Directory-Benutzer für domainlose gMSA

  Wenn Sie Domainless verwendengMSA, ist der Container nicht mit der Domain verbunden. Andere Anwendungen, die auf dem Container ausgeführt werden, können die Anmeldeinformationen nicht für den Zugriff auf die Domäne verwenden. Aufgaben, die eine andere Domain verwenden, können auf demselben Container ausgeführt werden. Sie geben den Namen eines Geheimnisses 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 ähnelt dem gMSA support for non-domain-joined container hosts-Feature. Weitere Informationen zum Windows-Feature finden Sie unter gMSA-Architektur und -Verbesserungen auf der Microsoft-Learn-Website.

  1. Konfigurieren Sie einen Benutzer in Ihrer Active Directory-Domäne. Der Benutzer im Active Directory muss berechtigt sein, auf das gMSA Dienstkonto zuzugreifen, das Sie für die Aufgaben verwenden.

  2. Sie haben ein VPC und Subnetze, die den Active Directory-Domänennamen auflösen können. Konfigurieren Sie die DHCP Optionen VPC with mit dem Domänennamen, der auf den Active Directory-Dienstnamen verweist. Informationen zur Konfiguration von DHCP Optionen für eine VPC finden Sie unter Arbeiten mit DHCP Optionssätzen im Amazon Virtual Private Cloud Cloud-Benutzerhandbuch.

  3. Erstellen Sie ein Geheimnis in AWS Secrets Manager.

  4. Erstellen Sie die Datei mit den Anmeldeinformationen.

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

2. Nachdem Sie den Active Directory-Benutzer eingerichtet haben, erstellen Sie ein Geheimnis in AWS Secrets Manager. Weitere Informationen finden Sie unter Ein AWS Secrets Manager -Secret erstellen.

3. Geben Sie den Benutzernamen, das Passwort und die Domäne des Benutzers in JSON Schlüssel-Wert-Paare einusername, die jeweils als password und domainName bezeichnet werden.

   {"username":"username","password":"passw0rd", "domainName":"example.com"}

4. Sie müssen der IAM Aufgabenausführungsrolle die folgenden Berechtigungen als Inline-Richtlinie hinzufügen. Dadurch erhält der credentials-fetcher-Daemon Zugriff auf das Secrets-Manager-Secret. Ersetzen Sie das MySecret Beispiel durch den Amazon-Ressourcennamen (ARN) Ihres Geheimnisses in der Resource Liste.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "secretsmanager:GetSecretValue"
         ],
         "Resource": [
           "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret"
         ]
       }
     ]
   }

   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.

5. Fügen Sie die Anmeldeinformationsspezifikation zu einem Amazon-S3-Bucket hinzu. Verweisen Sie dann im credentialSpecs Feld der Aufgabendefinition auf den Amazon-Ressourcennamen (ARN) des Amazon S3-Buckets.

   {
       "family": "",
       "executionRoleArn": "",
       "containerDefinitions": [
           {
               "name": "",
               ...
               "credentialSpecs": [
                   "credentialspecdomainless:arn:aws:s3:::${BucketName}/${ObjectName}"
               ],
               ...
           }
       ],
       ...
   }

   Um Ihren Aufgaben Zugriff auf den S3-Bucket zu gewähren, fügen Sie der ECS IAM Amazon-Aufgabenausführungsrolle die folgenden Berechtigungen als Inline-Richtlinie hinzu.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor",
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:ListObject"
               ],
               "Resource": [
                   "arn:aws:s3:::{bucket_name}",
                   "arn:aws:s3:::{bucket_name}/{object}"
               ]
           }
       ]
   }

Anmeldeinformationsspezifikationsdatei

Amazon ECS verwendet eine Active Directory-Anmeldeinformationsspezifikationsdatei (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"
            }
        }
    }
}

Eine erstellen CredSpec und auf einen Amazon S3 hochladen

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 auf der Microsoft-Learn-Website.

Nachdem Sie die Datei mit den Anmeldeinformationen erstellt haben, laden Sie sie in einen Amazon S3 S3-Bucket hoch. Kopieren Sie die CredSpec-Datei auf den Computer oder die Umgebung, in der Sie AWS CLI -Befehle ausführen.

Führen Sie den folgenden AWS CLI Befehl aus, CredSpec um das auf Amazon S3 hochzuladen. Ersetzen Sie amzn-s3-demo-bucket durch den Namen Ihres Amazon-S3-Buckets. Sie können die Datei als Objekt in einem beliebigen Bucket und an einem beliebigen Ort speichern, müssen jedoch in der Richtlinie, die Sie der Aufgabenausführungsrolle zuordnen, den Zugriff auf diesen Bucket und diesen Speicherort gewähren.

Verwenden PowerShell Sie für den folgenden Befehl:

$ Write-S3Object -BucketName "amzn-s3-demo-bucket" -Key "ecs-domainless-gmsa-credspec" -File "gmsa-cred-spec.json"

Der folgende AWS CLI Befehl verwendet Backslash-Fortsetzungszeichen, die von sh und kompatiblen Shells verwendet werden.

$ aws s3 cp gmsa-cred-spec.json \
s3://amzn-s3-demo-bucket/ecs-domainless-gmsa-credspec