Überlegungen Voraussetzungen Architektur Verwenden von ECS Exec Protokollierung mit ECS Exec Verwenden von IAM-Richtlinien, um den Zugriff auf ECS Exec zu beschränken

Überwachen Sie Amazon ECS-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 SSH-Schlüssel verwalten zu müssen. 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. Beispielsweise können Sie ECS Exec in einem Entwicklungsumfeld verwenden, um problemlos mit verschiedenen Prozessen in Ihren Containern zu interagieren und Ihre Anwendungen zu beheben. Und in Produktionsszenarien können Sie sich damit bruchsicheren Zugriff auf Ihre Container verschaffen, um Probleme zu debuggen.

Sie können Befehle in einem laufenden Linux- oder Windows-Container mit ECS Exec über die Amazon ECS-API AWS Command Line Interface (AWS CLI) oder die AWS SDKs AWS Copilot-CLI ausführen. Einzelheiten zur Verwendung von ECS Exec sowie eine Videoanleitung mit der AWS Copilot-CLI finden Sie im Copilot 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 aller 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 sich mit den folgenden Aspekten vertraut machen, die mit ECS Exec verbunden sind:

ECS Exec wird derzeit nicht mit dem unterstützt. AWS Management Console

Auf der Detailseite des Clusters werden die Protokollierung und der vom AWS KMS Kunden verwaltete Schlüssel angezeigt, die zur Verschlüsselung der Daten zwischen dem lokalen Client und dem Container verwendet werden.
ECS Exec 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.
ECS Exec wird für Aufgaben unterstützt, die auf der folgenden Infrastruktur ausgeführt werden:
- Linux-Container auf Amazon EC2 auf jedem Amazon ECS-optimierten AMI, 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 für Amazon ECS optimierten Windows AMIs (mit der Container-Agent-Version 1.56 oder höher):
  - Amazon-ECS-optimierter Windows Server 2022 Full AMI
  - Amazon-ECS-optimierter Windows Server 2022 Core AMI
  - Amazon-ECS-optimierter Windows Server 2019 Full AMI
  - Amazon-ECS-optimierter Windows Server 2019 Core AMI
  - Amazon-ECS-optimiertes Windows Server 20H2 Core AMI
Wenn Sie einen HTTP-Proxy für Ihre Aufgabe konfiguriert haben, setzen Sie die NO_PROXY Umgebungsvariable auf"NO_PROXY=169.254.169.254,169.254.170.2", um den Proxy für EC2 Instance-Metadaten und IAM-Rollenverkehr zu umgehen. Wenn Sie die NO_PROXY Umgebungsvariable nicht konfigurieren, kann es beim Abrufen von Instanzmetadaten oder IAM-Rollenanmeldedaten vom Metadaten-Endpunkt im Container zu Fehlern kommen. Wenn Sie die NO_PROXY Umgebungsvariable als empfohlen festlegen, werden die Metadaten und der IAM-Verkehr gefiltert, sodass Anfragen 169.254.169.254 and 169.254.170.2 nicht über den Proxy weitergeleitet werden. HTTP
ECS Exec und Amazon VPC
- Wenn Sie Amazon-VPC-Endpunkte als Schnittstelle mit Amazon ECS verwenden, müssen Sie die Schnittstelle Amazon-VPC-Endpunkte für Systems Manager Session Manager (ssmmessages) erstellen. Weitere Informationen zu Systems Manager Manager-VPC-Endpunkten finden Sie im Benutzerhandbuch unter Verwenden AWS PrivateLink zum Einrichten eines VPC-Endpoints für Session Manager.AWS Systems Manager
- Wenn Sie die Schnittstelle Amazon VPC-Endpunkte mit Amazon ECS verwenden und AWS KMS key für die Verschlüsselung verwenden, müssen Sie die Schnittstelle Amazon-VPC-Endpunkt für AWS KMS key erstellen. Weitere Informationen finden Sie unter Verbinden mit 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 (Amazon VPC-Endpoints) 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 Manager-VPC-Endpunkten finden Sie im Benutzerhandbuch unter Verwenden AWS PrivateLink zum Einrichten eines VPC-Endpoints für Session Manager.AWS Systems Manager
ECS Exec und SSM
- Wenn ein Benutzer Befehle für einen Container mit ECS Exec ausführt, werden diese Befehle als der root-Benutzer ausgeführt. Der SSM Agent und seine untergeordneten Prozesse werden auch dann als Root ausgeführt, 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.
- Obwohl das Starten von SSM-Sitzungen außerhalb der execute-command-Aktion möglich ist, führt dies dazu, dass die Sitzungen nicht protokolliert und gegen das Sitzungslimit gezählt werden. Wir empfehlen, diesen Zugriff einzuschränken, indem Sie die ssm:start-session-Aktion mit einer IAM-Richtlinie verweigern. 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.
ECS Exec verwendet etwas CPU und Arbeitsspeicher. Sie sollten dies berücksichtigen, wenn Sie die CPU- und Arbeitsspeicherressourcenzuordnungen in Ihrer Aufgabendefinition 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-Namespace (PID) haben. Wenn Sie einen PID-Namespace in einer Aufgabe freigeben, können Sie ECS-Exec-Sitzungen nur in einem Container starten.
Für die ECS Exec-Sitzung ist eine Zeitüberschreitung von 20 Minuten konfiguriert. Dieser Wert kann nicht geändert werden.
Sie können ECS Exec nicht für vorhandene Aufgaben aktivieren. Es kann nur für neue Aufgaben aktiviert werden.
Sie können ECS Exec nicht verwendenrun-task, wenn Sie eine Aufgabe auf einem Cluster starten, der verwaltete Skalierung mit asynchroner Platzierung verwendet (eine Aufgabe ohne Instanz starten).
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 Aufgaben-IAM-Rollen.
Für ECS Exec gelten Versionsanforderungen, die davon abhängen, ob Ihre Aufgaben bei Amazon gehostet werden EC2 oder AWS Fargate:
- Wenn Sie Amazon verwenden EC2, müssen Sie ein für Amazon ECS optimiertes AMI verwenden, 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-optimiert 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

ECS Exec verwendet den 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 notwendigen SSM Agent-Binärdateien in den Container eingebunden werden. Der Amazon ECS oder 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 ECS Exec

Ä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 Prozesse des Zombie-SSM-Agents 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"
}

Aktivieren von ECS Exec für Ihre Aufgaben und Services

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 für die Verwendung bereit 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,
            ...
        }
    ]
}

Ausführen von Befehlen mit ECS Exec

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 ECS unterstützt nur das Initiieren interaktiver Sitzungen. Daher müssen Sie das --interactive-Flag verwenden.

Mit dem folgenden Befehl wird ein interaktiver /bin/sh Befehl container-name für einen Container ausgeführt, der nach einer Aufgabe mit der task-id ID benannt ist.

Das 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

Einschalten der Protokollierung Ihrer Aufgaben und Dienste

Wichtig

Weitere Informationen zur CloudWatch Preisgestaltung finden Sie unter CloudWatch Preise. Amazon ECS stellt außerdem Überwachungsmetriken bereit, die ohne zusätzliche Gebühren bereitgestellt 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. Standardmäßig werden CloudWatch Protokolle mithilfe des awslogs Protokolltreibers, der in Ihrer Aufgabendefinition konfiguriert ist, an Logs gesendet. Wenn Sie eine benutzerdefinierte Konfiguration bereitstellen möchten, AWS CLI unterstützt der ein --configuration Flag sowohl für die create-cluster update-cluster Befehle als auch. Das Container-Image muss script installiert seincat, 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.

Für Amazon CloudWatch Logs oder Amazon S3 Logging sind IAM-Berechtigungen erforderlich

Um die Protokollierung zu aktivieren, benötigt die Amazon-ECS-Aufgabenrolle, die in Ihrer Aufgabendefinition referenziert 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.

Für die Verschlüsselung mit Ihrem eigenen AWS KMS key (KMS-Schlüssel) sind IAM-Berechtigungen erforderlich

Standardmäßig verwenden die zwischen Ihrem lokalen Client und dem Container übertragenen Daten die TLS 1.2-Verschlüsselung, die dies AWS ermöglicht. Um Daten mit Ihrem eigenen KMS-Schlüssel weiter zu verschlüsseln, müssen Sie einen KMS-Schlüssel erstellen und die kms:Decrypt-Berechtigung für Ihre Aufgaben-IAM-Rolle 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 Erstellen von Schlüsseln.

Sie fügen Ihrer Task-IAM-Rolle, für die die AWS KMS Berechtigungen erforderlich sind, die folgende Inline-Richtlinie hinzu. Weitere Informationen finden Sie unter ECS Exec-Berechtigungen.


{
    "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, muss dem Benutzer oder der Gruppe, der/die die execute-command-Aktion verwendet, die kms:GenerateDataKey-Berechtigung gewährt werden.

Die folgende Beispielrichtlinie für Ihren Benutzer oder Ihre Gruppe enthält die erforderliche Berechtigung, Ihren eigenen KMS-Schlüssel zu verwenden. 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"
        }
    ]
}

Verwenden von IAM-Richtlinien, um den Zugriff auf ECS Exec zu beschränken

Sie beschränken den Benutzerzugriff auf die API-Aktion „Befehl ausführen“, indem Sie einen oder mehrere der folgenden IAM-Policy-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 dem folgenden Beispiel einer IAM-Richtlinie können Benutzer Befehle in Containern ausführen, die innerhalb von Aufgaben mit einem Tag ausgeführt werden, das einen environment-Schlüssel und development-Wert hat und in einem Cluster mit dem Namen 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"
                }
            }
        }
    ]
}

Im folgenden IAM-Richtlinienbeispiel können Benutzer die execute-command-API nicht verwenden, wenn der Containername production-app lautet.


{
    "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 deaktiviert 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-commandAPI-Aktion nur Task- und Clusterressourcen in einer Anforderung enthält, werden nur Cluster- und Task-Tags ausgewertet.

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

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

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

Nachfolgend finden Sie eine Beispiel-IAM-Richtlinie, die den Zugriff auf die ssm:start-session-Aktion für Tasks in allen Regionen mit einem angegebenen 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/*"
            ]
        }
    ]
}

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


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

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Problembehandlung FAQs

Empfehlungen zu Compute Optimizer