Überwachen Sie ECS Amazon-Container mit ECS Exec - Amazon Elastic Container Service
Überlegungen Voraussetzungen ArchitekturVerwenden von Exec ECSProtokollierung mit ECS ExecVerwendung von IAM Richtlinien zur Beschränkung des Zugriffs auf ECS Exec

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.

Überwachen Sie ECS Amazon-Container mit ECS Exec

Mit Amazon ECS Exec können Sie direkt mit Containern interagieren, ohne zuerst mit dem Host-Container-Betriebssystem interagieren, eingehende Ports öffnen oder Schlüssel verwalten zu müssen. SSH Sie können ECS Exec verwenden, um Befehle in einem Container auszuführen oder eine Shell für einen Container zu erhalten, der auf einer EC2 Amazon-Instance oder auf AWS Fargate einem läuft. Dies erleichtert das Sammeln von Diagnoseinformationen und die schnelle Fehlerbehebung. In einem Entwicklungskontext können Sie ECS Exec beispielsweise verwenden, um auf einfache Weise mit verschiedenen Prozessen in Ihren Containern zu interagieren und Fehler in Ihren Anwendungen zu beheben. Und in Produktionsszenarien können Sie es verwenden, um Sicherheitslücken auf Ihre Container zuzugreifen, um Probleme zu debuggen.

Sie können Befehle in einem laufenden Linux- oder Windows-Container mit ECS Exec von Amazon ECSAPI, AWS Command Line Interface (AWS CLI) AWS SDKs, oder dem AWS CLI Copilot ausführen. Einzelheiten zur Verwendung von ECS Exec sowie eine Videoanleitung zur Verwendung des Copiloten finden Sie im AWS Copilot CLI GitHub Dokumentation.

Sie können ECS Exec auch verwenden, um strengere Richtlinien für die Zugriffskontrolle aufrechtzuerhalten. Wenn Sie dieses Feature selektiv aktivieren, können Sie steuern, wer Befehle ausführen kann und für welche Tasks diese Befehle ausgeführt werden können. Mit einem Protokoll der einzelnen Befehle und ihrer Ausgabe können Sie mit ECS Exec anzeigen, welche Aufgaben ausgeführt wurden, und Sie können überprüfen, wer CloudTrail auf einen Container zugegriffen hat.

Überlegungen

Zu diesem Thema sollten Sie mit den folgenden Aspekten der Verwendung von ECS Exec vertraut sein:

  • ECSExec wird derzeit nicht mit dem unterstützt. AWS Management Console

  • ECSExec funktioniert möglicherweise nicht wie erwartet, wenn es auf Betriebssystemen läuft, die nicht von Systems Manager unterstützt werden. Informationen zu den unterstützten Betriebssystemen finden Sie im AWS Systems Manager Benutzerhandbuch unter Betriebssystemtypen.

  • ECSExec wird für Aufgaben unterstützt, die auf der folgenden Infrastruktur ausgeführt werden:

    • Linux-Container auf Amazon auf allen EC2 ECS Amazon-optimierten ContainernAMI, einschließlich Bottlerocket

    • Linux- und Windows-Container auf externen Instances (Amazon ECS Anywhere)

    • Linux- und Windows-Container auf AWS Fargate

    • Windows-Container EC2 auf Amazon unter den folgenden ECS Amazon-optimierten Windows-Versionen AMIs (mit der Container-Agent-Version 1.56 oder höher):

      • ECSAmazon-optimierter Windows Server 2022 Vollversion AMI

      • Für Amazon ECS optimierter Windows Server 2022 Core AMI

      • ECSAmazon-optimierter Windows Server 2019 Vollversion AMI

      • Für Amazon ECS optimierter Windows Server 2019 Core AMI

      • Für Amazon ECS optimierter Windows Server 20H2 Core AMI

  • ECSExec und Amazon VPC

    • Wenn Sie VPC Amazon-Schnittstellenendpunkte mit Amazon verwendenECS, müssen Sie die VPC Amazon-Schnittstellenendpunkte für den Systems Manager Session Manager () ssmmessages erstellen. Weitere Informationen zu Systems Manager VPC Manager-Endpunkten finden Sie im AWS Systems Manager Benutzerhandbuch unter Verwenden AWS PrivateLink zum Einrichten eines VPC Endpunkts für Session Manager.

    • Wenn Sie VPC Amazon-Schnittstellenendpunkte mit Amazon verwenden und diese AWS KMS key für die Verschlüsselung verwendenECS, müssen Sie die Schnittstelle erstellen, für AWS KMS key die Amazon VPC Endpoint verwendet wird. Weitere Informationen finden Sie unter Herstellen einer Verbindung AWS KMS key über einen VPC Endpunkt im AWS Key Management Service Entwicklerhandbuch.

    • Wenn Sie Aufgaben haben, die auf EC2 Amazon-Instances ausgeführt werden, verwenden Sie den awsvpc Netzwerkmodus. Wenn Sie keinen Internetzugang haben (z. B. nicht für die Verwendung eines NAT Gateways konfiguriert), müssen Sie die Schnittstelle (VPCAmazon-Endpunkte) für den Systems Manager Session Manager (ssmmessages) erstellen. Weitere Informationen zu Überlegungen zum awsvpc-Netzwerkmodus finden Sie unter Überlegungen. Weitere Informationen zu Systems Manager VPC Manager-Endpunkten finden Sie im AWS Systems Manager Benutzerhandbuch unter Verwenden AWS PrivateLink zum Einrichten eines VPC Endpunkts für Session Manager.

  • ECSExec und SSM

    • Wenn ein Benutzer mit ECS Exec Befehle in einem Container ausführt, werden diese Befehle als Benutzer ausgeführt. root Der SSM Agent und seine untergeordneten Prozesse werden als Root-Benutzer ausgeführt, auch wenn Sie eine Benutzer-ID für den Container angeben.

    • Der SSM Agent erfordert, dass in das Container-Dateisystem geschrieben werden kann, um die erforderlichen Verzeichnisse und Dateien zu erstellen. Daher wird das Schreibschützen der Root-Dateisystem mit dem readonlyRootFilesystem-Aufgabendefinitionsparameter oder eine andere Methode nicht unterstützt.

    • Es ist zwar möglich, SSM Sitzungen außerhalb der execute-command Aktion zu starten, dies führt jedoch dazu, dass die Sitzungen nicht protokolliert und auf das Sitzungslimit angerechnet werden. Wir empfehlen, diesen Zugriff einzuschränken, indem die ssm:start-session Aktion mithilfe einer IAM Richtlinie verweigert wird. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf die Aktion „Sitzung starten“.

  • Die folgenden Funktionen werden als Sidecar-Container ausgeführt. Daher müssen Sie den Namen des Containers angeben, für den der Befehl ausgeführt werden soll.

    • Laufzeit-Überwachung

    • Service Connect

  • Benutzer können alle Befehle ausführen, die im Container-Kontext verfügbar sind. Die folgenden Aktionen können zu verwaisten und Zombie-Prozessen führen: Beenden des Hauptprozesses des Containers, Beenden des Befehls-Agenten und Löschen von Abhängigkeiten. Um Zombie-Prozesse zu bereinigen, empfehlen wir Ihnen, das initProcessEnabled-Flag an Ihre Aufgabendefinition anzufügen.

  • ECSExec verwendet etwas CPU und Speicher. Dies sollten Sie berücksichtigen, wenn Sie in Ihrer Aufgabendefinition die Speicherressourcenzuweisungen CPU und die Speicherressourcenzuweisungen angeben.

  • Sie müssen AWS CLI Version 1.22.3 oder höher oder AWS CLI Version 2.3.6 oder höher verwenden. Informationen zur Aktualisierung von finden Sie unter Installation oder Aktualisierung der neuesten Version von AWS CLI im AWS Command Line Interface Benutzerhandbuch Version 2. AWS CLI

  • Sie können nur eine ECS Exec-Sitzung pro Prozess-ID (PID) -Namespace haben. Wenn Sie einen PID Namespace in einer Aufgabe gemeinsam nutzen, können Sie nur ECS Exec-Sitzungen in einem Container starten.

  • Die ECS Exec-Sitzung hat eine Leerlaufzeit von 20 Minuten. Dieser Wert kann nicht geändert werden.

  • Sie können ECS Exec nicht für bestehende Aufgaben aktivieren. Es kann nur für neue Aufgaben aktiviert werden.

  • Sie können ECS Exec nicht verwenden, wenn Sie eine Aufgabe auf einem Cluster starten, der verwaltete Skalierung mit asynchroner Platzierung verwendet (eine Aufgabe ohne Instanz starten). run-task

  • Sie können ECS Exec nicht für Microsoft Nano Server-Container ausführen.

Voraussetzungen

Bevor Sie mit der Verwendung von ECS Exec beginnen, stellen Sie sicher, dass Sie die folgenden Aktionen abgeschlossen haben:

  • Installieren und Konfigurieren der AWS CLI. Weitere Informationen finden Sie unter Erste Schritte mit dem AWS CLI.

  • Installieren Sie das Session Manager-Plug-In für AWS CLI. Weitere Informationen finden Sie unter Installieren des Session Manager-Plugins für AWS CLI.

  • Sie müssen eine Aufgabenrolle mit den entsprechenden Berechtigungen für ECS Exec verwenden. Weitere Informationen finden Sie unter IAMAufgabenrolle.

  • ECSExec hat Versionsanforderungen, die davon abhängen, ob Ihre Aufgaben bei Amazon gehostet werden EC2 oder AWS Fargate:

    • Wenn Sie Amazon verwendenEC2, müssen Sie ein für Amazon ECS optimiertes Produkt verwendenAMI, das nach dem 20. Januar 2021 veröffentlicht wurde, mit einer Agentenversion von 1.50.2 oder höher. Weitere Informationen finden Sie unter Amazon ECS Optimized AMIs.

    • Wenn Sie verwenden AWS Fargate, müssen Sie die Plattformversion 1.4.0 oder höher (Linux) oder 1.0.0 (Windows) verwenden. Weitere Informationen finden Sie unter AWS Fargate -Plattformversionen.

Architektur

ECSExec verwendet AWS Systems Manager (SSM) Session Manager, um eine Verbindung mit dem laufenden Container herzustellen, und verwendet AWS Identity and Access Management (IAM) -Richtlinien, um den Zugriff auf laufende Befehle in einem laufenden Container zu steuern. Dies wird ermöglicht, indem die erforderlichen SSM Agent-Binärdateien per Binärdatei in den Container eingebunden werden. Amazon ECS oder der AWS Fargate Agent ist dafür verantwortlich, den SSM Core-Agenten im Container zusammen mit Ihrem Anwendungscode zu starten. Weitere Informationen erhalten Sie unter Systems Manager Session Manager.

Sie können anhand des ExecuteCommand Event in überprüfen, welcher Benutzer auf den Container zugegriffen hat, AWS CloudTrail und jeden Befehl (und seine Ausgabe) in Amazon S3 oder Amazon CloudWatch Logs protokollieren. Um Daten zwischen dem lokalen Client und dem Container mit Ihrem eigenen Verschlüsselungsschlüssel zu verschlüsseln, müssen Sie den Schlüssel AWS Key Management Service (AWS KMS) angeben.

Verwenden von Exec ECS

Änderungen an optionalen Aufgabendefinition

Wenn Sie den Parameter für die Aufgabendefinition initProcessEnabled auf setzentrue, wird der Init-Prozess innerhalb des Containers gestartet. Dadurch werden alle gefundenen untergeordneten SSM Zombie-Agent-Prozesse entfernt. Folgendes ist ein Beispiel.

{
    "taskRoleArn": "ecsTaskRole",
    "networkMode": "awsvpc",
    "requiresCompatibilities": [
        "EC2",
        "FARGATE"
    ],
    "executionRoleArn": "ecsTaskExecutionRole",
    "memory": ".5 gb",
    "cpu": ".25 vcpu",
    "containerDefinitions": [
        {
            "name": "amazon-linux",
            "image": "amazonlinux:latest",
            "essential": true,
            "command": ["sleep","3600"],
            "linuxParameters": {
                "initProcessEnabled": true
            }
        }
    ],
    "family": "ecs-exec-task"
}

ECSExec für Ihre Aufgaben und Dienste einschalten

Sie können die ECS Exec-Funktion für Ihre Dienste und eigenständigen Aufgaben aktivieren, indem Sie das --enable-execute-command Flag angeben, wenn Sie einen der folgenden AWS CLI Befehle verwenden: create-service, update-servicestart-task, oder. run-task

Wenn Sie beispielsweise den folgenden Befehl ausführen, wird die ECS Exec-Funktion für einen neu erstellten Dienst aktiviert, der auf Fargate ausgeführt wird. Weitere Informationen zum Erstellen von Services finden Sie unter create-service.

aws ecs create-service \
    --cluster cluster-name \
    --task-definition task-definition-name \
    --enable-execute-command \
    --service-name service-name \
    --launch-type FARGATE \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" \
    --desired-count 1

Nachdem Sie ECS Exec für eine Aufgabe aktiviert haben, können Sie den folgenden Befehl ausführen, um zu bestätigen, dass die Aufgabe einsatzbereit ist. Wenn die lastStatus-Eigenschaft des ExecuteCommandAgent als RUNNING aufgelistet wird und die enableExecuteCommand-Eigenschaft auf true festgelegt ist, dann ist Ihre Aufgabe fertig.

aws ecs describe-tasks \
    --cluster cluster-name \
    --tasks task-id

Das folgende Ausgabeschnippsel ist ein Beispiel davon, was Sie sehen könnten.

{
    "tasks": [
        {
            ...
            "containers": [
                {
                    ...
                    "managedAgents": [
                        {
                            "lastStartedAt": "2021-03-01T14:49:44.574000-06:00",
                            "name": "ExecuteCommandAgent",
                            "lastStatus": "RUNNING"
                        }
                    ]
                }
            ],
            ...
            "enableExecuteCommand": true,
            ...
        }
    ]
}

Befehle mit ECS Exec ausführen

Nachdem Sie bestätigt haben, dass ExecuteCommandAgent ausgeführt wird, können Sie eine interaktive Shell in Ihrem Container mit dem folgenden Befehl öffnen. Wenn Ihre Aufgabe mehrere Container enthält, müssen Sie den Containernamen mithilfe des --container-Flag angeben. Amazon unterstützt ECS nur das Initiieren interaktiver Sitzungen, daher müssen Sie das --interactive Flag verwenden.

Mit dem folgenden Befehl wird ein interaktiver /bin/sh Befehl für einen Container mit dem Namen ausgeführt container-name für eine Aufgabe mit der ID von task-id.

Das Tool task-id ist der Amazon-Ressourcenname (ARN) der Aufgabe.

aws ecs execute-command --cluster cluster-name \
    --task task-id \
    --container container-name \
    --interactive \
    --command "/bin/sh"

Protokollierung mit ECS Exec

Aktivieren Sie die Protokollierung Ihrer Aufgaben und Dienste

Wichtig

Weitere Informationen zur CloudWatch Preisgestaltung finden Sie unter CloudWatch Preise. Amazon bietet ECS auch Monitoring-Metriken, die ohne zusätzliche Kosten zur Verfügung gestellt werden. Weitere Informationen finden Sie unter Überwachen Sie Amazon ECS mit CloudWatch.

Amazon ECS bietet eine Standardkonfiguration für die Protokollierung von Befehlen, die mit ECS Exec ausgeführt werden, indem CloudWatch Protokolle mithilfe des awslogs Protokolltreibers, der in Ihrer Aufgabendefinition konfiguriert ist, an Logs gesendet werden. Wenn Sie eine benutzerdefinierte Konfiguration bereitstellen möchten, unterstützt AWS CLI ein --configuration-Flag sowohl für die create-cluster- und update-cluster-Befehle. Es ist auch wichtig zu wissen, dass das Container-Image installiert sein cat mussscript, damit die Befehlsprotokolle korrekt in Amazon S3 oder CloudWatch Logs hochgeladen werden können. Weitere Informationen zum Erstellen von Clustern finden Sie unter create-cluster.

Anmerkung

Diese Konfiguration verarbeitet nur die Protokollierung der execute-command-Sitzung. Dies wirkt sich nicht auf die Protokollierung Ihrer Anwendung aus.

Das folgende Beispiel erstellt einen Cluster und protokolliert dann die Ausgabe in Ihren CloudWatch Logs LogGroup named cloudwatch-log-group-name und Ihrem Amazon S3 S3-Bucket nameds3-bucket-name.

Sie müssen einen vom AWS KMS Kunden verwalteten Schlüssel verwenden, um die Protokollgruppe zu verschlüsseln, wenn Sie die CloudWatchEncryptionEnabled Option auf true setzen. Informationen zum Verschlüsseln der Protokollgruppe finden Sie unter Verschlüsseln von Protokolldaten im Abschnitt CloudWatch Protokolle mithilfe von AWS Key Management Service Protokollen im Amazon CloudWatch Logs Benutzerhandbuch.

aws ecs create-cluster \
    --cluster-name cluster-name \
    --configuration executeCommandConfiguration="{ \
        kmsKeyId=string, \
        logging=OVERRIDE, \
        logConfiguration={ \
            cloudWatchLogGroupName=cloudwatch-log-group-name, \
            cloudWatchEncryptionEnabled=true, \
            s3BucketName=s3-bucket-name, \
            s3EncryptionEnabled=true, \
            s3KeyPrefix=demo \
        } \
    }"

Die logging Eigenschaft bestimmt das Verhalten der Protokollierungsfunktion von ECS Exec:

  • NONE: Die Protokollierung ist ausgeschaltet.

  • DEFAULT: Protokolle werden an den konfigurierten awslogs Treiber gesendet. Wenn der Treiber nicht konfiguriert ist, wird kein Protokoll gespeichert.

  • OVERRIDE: Protokolle werden an die bereitgestellten Amazon CloudWatch Logs- LogGroup, Amazon S3 S3-Bucket oder beide gesendet.

IAMFür Amazon CloudWatch Logs oder Amazon S3 Logging erforderliche Berechtigungen

Um die Protokollierung zu aktivieren, benötigt die ECS Amazon-Aufgabenrolle, auf die in Ihrer Aufgabendefinition verwiesen wird, zusätzliche Berechtigungen. Diese zusätzlichen Berechtigungen können der Aufgabenrolle als Richtlinie hinzugefügt werden. Sie unterscheiden sich, je nachdem, ob Sie Ihre Protokolle an Amazon CloudWatch Logs oder Amazon S3 weiterleiten.

Amazon CloudWatch Logs

Die folgende Beispielrichtlinie fügt die erforderlichen Amazon CloudWatch Logs-Berechtigungen hinzu.

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
               "logs:CreateLogStream",
               "logs:DescribeLogStreams",
               "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:region:account-id:log-group:/aws/ecs/cloudwatch-log-group-name:*"
        }
   ]
}
Amazon S3

Das folgende Beispiel einer Richtlinie fügt die erforderlichen Amazon-S3-Berechtigungen hinzu.

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Action": [
               "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
           "Effect": "Allow",
           "Action": [
               "s3:GetEncryptionConfiguration"
           ],
           "Resource": "arn:aws:s3:::s3-bucket-name"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::s3-bucket-name/*"
        }
    ]
   }

IAMBerechtigungen, die für die Verschlüsselung mit Ihrem eigenen AWS KMS key (KMSSchlüssel) erforderlich sind

Standardmäßig verwenden die Daten, die zwischen Ihrem lokalen Client und dem Container übertragen werden, die TLS 1.2-Verschlüsselung, die AWS Folgendes bietet: Um Daten mit Ihrem eigenen KMS Schlüssel weiter zu verschlüsseln, müssen Sie einen KMS Schlüssel erstellen und die kms:Decrypt entsprechende Berechtigung zu Ihrer IAM Aufgabenrolle hinzufügen. Diese Berechtigung wird von Ihrem Container verwendet, um die Daten zu entschlüsseln. Weitere Informationen zum Erstellen eines KMS Schlüssels finden Sie unter Schlüssel erstellen.

Sie fügen Ihrer IAM Aufgabenrolle, für die die AWS KMS Berechtigungen erforderlich sind, die folgende Inline-Richtlinie hinzu. Weitere Informationen finden Sie unter ECSBerechtigungen für Führungskräfte.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "kms-key-arn"
        }
    ]
}

Damit die Daten mit Ihrem eigenen KMS Schlüssel verschlüsselt werden können, muss dem Benutzer oder der Gruppe, die die execute-command Aktion verwendet, die kms:GenerateDataKey entsprechende Genehmigung erteilt werden.

Die folgende Beispielrichtlinie für Ihren Benutzer oder Ihre Gruppe enthält die erforderliche Berechtigung zur Verwendung Ihres eigenen KMS Schlüssels. Sie müssen den Amazon-Ressourcennamen (ARN) Ihres KMS Schlüssels angeben.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": "kms-key-arn"
        }
    ]
}

Verwendung von IAM Richtlinien zur Beschränkung des Zugriffs auf ECS Exec

Sie beschränken den Benutzerzugriff auf die API Aktion „Befehl ausführen“, indem Sie einen oder mehrere der folgenden IAM Richtlinien-Bedingungsschlüssel verwenden:

  • aws:ResourceTag/clusterTagKey

  • ecs:ResourceTag/clusterTagKey

  • aws:ResourceTag/taskTagKey

  • ecs:ResourceTag/taskTagKey

  • ecs:container-name

  • ecs:cluster

  • ecs:task

  • ecs:enable-execute-command

Mit der folgenden IAM Beispielrichtlinie können Benutzer Befehle in Containern ausführen, die innerhalb von Aufgaben mit einem Tag ausgeführt werden, das über einen environment Schlüssel und einen development Wert verfügt, und in einem Cluster, der benannt ist. cluster-name

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:ExecuteCommand",
                "ecs:DescribeTasks"
            ],
         "Resource": [
                "arn:aws:ecs:region:aws-account-id:task/cluster-name/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ecs:ResourceTag/environment": "development"
                }
            }
        }
    ]
}

Mit dem folgenden IAM Richtlinienbeispiel können Benutzer den nicht verwenden, execute-command API wenn der Container-Name lautetproduction-app.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ecs:ExecuteCommand"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {                    
                    "ecs:container-name": "production-app"
                }
            }
        }
    ]
}

Mit der folgenden IAM Richtlinie können Benutzer Aufgaben nur starten, wenn ECS Exec ausgeschaltet ist.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:RunTask",
                "ecs:StartTask",
                "ecs:CreateService",
                "ecs:UpdateService"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {                    
                    "ecs:enable-execute-command": "false"
                }
            }
        }
    ]
}
Anmerkung

Da die execute-command API Aktion nur Aufgaben- und Clusterressourcen in einer Anforderung enthält, werden nur Cluster- und Task-Tags ausgewertet.

Weitere Informationen zu IAM Policy-Bedingungsschlüsseln finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für Amazon Elastic Container Service in der Service Authorization Reference.

Beschränken des Zugriffs auf die Aktion „Sitzung starten“

Das Starten von SSM Sitzungen auf Ihrem Container außerhalb von ECS Exec ist zwar möglich, dies kann jedoch dazu führen, dass die Sitzungen nicht protokolliert werden. Sitzungen, die außerhalb von ECS Exec gestartet wurden, werden ebenfalls auf das Sitzungskontingent angerechnet. Wir empfehlen, diesen Zugriff einzuschränken, indem Sie die ssm:start-session Aktion direkt für Ihre ECS Amazon-Aufgaben mithilfe einer IAM Richtlinie verweigern. Sie können den Zugriff auf alle ECS Amazon-Aufgaben oder auf bestimmte Aufgaben basierend auf den verwendeten Tags verweigern.

Im Folgenden finden Sie ein Beispiel für eine IAM Richtlinie, die den Zugriff auf die ssm:start-session Aktion für Aufgaben in allen Regionen mit einem bestimmten Clusternamen verweigert. Optional können Sie einen Platzhalter mit cluster-name einschließen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ecs:region:aws-account-id:task/cluster-name/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ]
        }
    ]
}

Im Folgenden finden Sie ein Beispiel IAM für eine Richtlinie, die den Zugriff auf die ssm:start-session Aktion für Ressourcen in allen Regionen verweigert, die mit Tag-Schlüssel Task-Tag-Key und Tag-Wert gekennzeichnet sind. Exec-Task

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": "arn:aws:ecs:*:*:task/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Task-Tag-Key": "Exec-Task"
                }
            }
        }
    ]
}

Hilfe zu Problemen, auf die Sie bei der Verwendung von Amazon ECS Exec stoßen könnten, finden Sie unter Problembehandlung mit Exec.