Surveillez les conteneurs Amazon ECS avec ECS Exec - Amazon Elastic Container Service
Considérations Prérequis ArchitectureUtilisation d'ECS ExecJournalisation à l'aide d'ECS ExecUtilisation de stratégies IAM pour limiter l'accès à ECS Exec

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Surveillez les conteneurs Amazon ECS avec ECS Exec

Avec Amazon ECS Exec, vous pouvez interagir directement avec les conteneurs sans avoir besoin d'interagir avec le système d'exploitation du conteneur hôte, d'ouvrir des ports entrants ou de gérer les clés SSH au préalable. Vous pouvez utiliser ECS Exec pour exécuter des commandes dans ou obtenir un shell vers un conteneur s'exécutant sur une instance Amazon EC2 ou sur AWS Fargate. Cela facilite la collecte des informations de diagnostic et la résolution rapide des erreurs. Par exemple, dans le cadre d'un développement, vous pouvez utiliser ECS Exec pour interagir facilement avec différents processus dans vos conteneurs et dépanner vos applications. Et dans les scénarios de production, vous pouvez l'utiliser pour accéder facilement à vos conteneurs afin de résoudre les problèmes.

Vous pouvez exécuter des commandes dans un conteneur Linux ou Windows en cours d'exécution à l'aide d'ECS Exec à partir de l'API Amazon ECS AWS Command Line Interface (AWS CLI), des AWS SDK ou de la CLI AWS Copilot. Pour plus de détails sur l'utilisation d'ECS Exec, ainsi qu'une présentation vidéo sur l'utilisation de la CLI AWS Copilot, consultez la documentation Copilot. GitHub

Vous pouvez également utiliser ECS Exec pour maintenir des politiques de contrôle d'accès plus strictes. En activant cette fonction de manière sélective, vous pouvez contrôler qui peut exécuter des commandes et sur quelles tâches. Avec un journal de chaque commande et de ses résultats, vous pouvez utiliser ECS Exec pour voir quelles tâches ont été exécutées et CloudTrail pour vérifier qui a accédé à un conteneur.

Considérations

Pour cette rubrique, vous devez connaître les aspects suivants liés à l'utilisation d'ECS Exec :

  • ECS Exec n'est actuellement pas pris en charge avec le AWS Management Console.

  • ECS Exec est pris en charge pour les tâches exécutées sur l'infrastructure suivante :

    • Conteneurs Linux sur Amazon EC2 sur n'importe quelle AMI optimisée pour Amazon ECS, y compris Bottlerocket

    • Conteneurs Linux et Windows sur des instances externes (Amazon ECS Anywhere)

    • Conteneurs Linux et Windows sur AWS Fargate

    • Conteneurs Windows sur Amazon EC2 sur les AMI Windows optimisées pour Amazon ECS suivantes (avec la version 1.56 ou ultérieure de l'agent de conteneur) :

      • AMI de Windows Server 2022 Full optimisée pour Amazon ECS

      • AMI de Windows Server 2022 Core optimisée pour Amazon ECS

      • AMI de Windows Server 2019 Full optimisée pour Amazon ECS

      • AMI de Windows Server 2019 Core optimisée pour Amazon ECS

      • AMI de Windows Server 20H2 Core optimisée pour Amazon ECS

  • ECS Exec et Amazon VPC

    • Si vous utilisez l'interface des points de terminaison Amazon VPC avec Amazon ECS, vous devez créer l'interface des points de terminaison Amazon VPC pour le Gestionnaire de sessions Systems Manager (ssmmessages). Pour plus d'informations sur les points de terminaison VPC de Systems Manager, consultez la section Utiliser AWS PrivateLink pour configurer un point de terminaison VPC pour Session Manager dans le guide de l'utilisateur.AWS Systems Manager

    • Si vous utilisez les points de terminaison Amazon VPC d'interface avec Amazon ECS, et que vous utilisez AWS KMS key pour le chiffrement, alors vous devez créer le point de terminaison Amazon VPC d'interface pour AWS KMS key. Pour plus d'informations, consultez Configuration à AWS KMS key via un point de terminaison de VPC dans le Guide du développeur AWS Key Management Service .

    • Lorsque vous avez des tâches exécutées sur des instances Amazon EC2, utilisez le mode awsvpc réseau. Si vous n'avez pas accès à Internet (par exemple si vous n'êtes pas configuré pour utiliser une passerelle NAT), vous devez créer l'interface (points de terminaison Amazon VPC) pour le gestionnaire de session Systems Manager (). ssmmessages Pour plus d'informations sur les considérations relatives au mode réseau awsvpc, veuillez consulter Considérations (langue française non garantie). Pour plus d'informations sur les points de terminaison VPC de Systems Manager, consultez la section Utiliser AWS PrivateLink pour configurer un point de terminaison VPC pour Session Manager dans le guide de l'utilisateur.AWS Systems Manager

  • ECS Exec et SSM

    • Lorsqu'un utilisateur exécute des commandes sur un conteneur à l'aide d'ECS Exec, ces commandes sont exécutées en tant qu'utilisateur root. Le SSM Agent et ses processus enfants s'exécutent en tant qu'utilisateur racine même lorsque vous spécifiez un ID d'utilisateur pour le conteneur.

    • L'agent SSM nécessite que le système de fichiers conteneur puisse être écrit dans le système de fichiers pour créer les répertoires et les fichiers requis. Par conséquent, il n'est pas possible de rendre le système de fichiers racine en lecture seule à l'aide du paramètre de définition de tâche readonlyRootFilesystem ou de toute autre méthode.

    • Il est possible de démarrer des sessions SSM en dehors de l'action execute-command, mais les sessions ne sont pas journalisées et sont comptabilisées afin de vérifier qu'elles ne dépassent pas la limite de session. Nous vous recommandons de limiter cet accès en refusant l'action ssm:start-session à l'aide d'une stratégie IAM. Pour plus d’informations, consultez Limitation de l'accès à l'action StartSession.

  • Les fonctionnalités suivantes s'exécutent en tant que conteneur de sidecar. Par conséquent, vous devez spécifier le nom du conteneur sur lequel exécuter la commande.

    • Surveillance d'exécution

    • Service Connect

  • Les utilisateurs peuvent exécuter toutes les commandes qui sont disponibles dans le contexte de conteneur. Les actions suivantes peuvent entraîner des processus orphelins et zombies : arrêt du processus principal du conteneur, arrêt de l'agent de commande et suppression des dépendances. Pour nettoyer les processus zombie, nous vous recommandons d'ajouter l'indicateur initProcessEnabled à votre définition de tâche.

  • ECS Exec utilise une partie du processeur et de la mémoire. Vous devez en tenir compte lorsque vous spécifiez les allocations de ressources CPU et mémoire dans votre définition de tâche.

  • Vous devez utiliser la AWS CLI version 1.22.3 ou une version ultérieure ou une AWS CLI version 2.3.6 ou une version ultérieure. Pour plus d'informations sur la mise à jour du AWS CLI, voir Installation ou mise à jour de la AWS CLI dernière version du Guide de l'AWS Command Line Interface utilisateur, version 2.

  • Vous ne pouvez avoir qu'une seule session ECS Exec par espace de noms d'ID de processus (PID). Si vous partagez un espace de noms PID dans une tâche, vous ne pouvez démarrer des sessions ECS Exec que dans un seul conteneur.

  • La session ECS Exec a une valeur de délai d'inactivité de 20 minutes. Cette valeur ne peut pas être modifiée.

  • Vous ne pouvez pas activer ECS Exec pour les tâches existantes. Vous ne pouvez l'activer que pour les nouvelles tâches.

  • Vous ne pouvez pas utiliser ECS Exec lorsque vous lancez une tâche sur un cluster qui utilise un dimensionnement géré avec un placement asynchrone (lancement d'une tâche sans instance). run-task

  • Vous ne pouvez pas exécuter ECS Exec sur des conteneurs Microsoft Nano Server.

Prérequis

Avant de commencer à utiliser ECS Exec, assurez-vous d'avoir effectué les actions suivantes :

  • Installation et configuration de l' AWS CLI. Pour plus d’informations, consultez AWS CLI.

  • Installez le plugin Session Manager pour AWS CLI. Pour de plus amples informations, veuillez consulter Install the Session Manager plugin for the AWS CLI.

  • Vous devez utiliser un rôle de tâche doté des autorisations appropriées pour ECS Exec. Pour plus d'informations, veuillez consulter Rôle IAM de tâche (langue française non garantie).

  • ECS Exec a des exigences de version selon que vos tâches sont hébergées sur Amazon EC2 ou AWS Fargate :

    • Si vous utilisez Amazon EC2, vous devez utiliser une AMI optimisée pour Amazon ECS publiée après le 20 janvier 2021 avec une version 1.50.2 ou supérieure de l'agent. Pour plus d'informations, consultez AMI optimisées pour Amazon ECS.

    • Si vous utilisez AWS Fargate, vous devez utiliser une version de plate-forme 1.4.0 ou supérieure (Linux) ou 1.0.0 (Windows). Pour plus d'informations, consultez Versions de plateforme AWS Fargate.

Architecture

ECS Exec utilise le gestionnaire de session AWS Systems Manager (SSM) pour établir une connexion avec le conteneur en cours d'exécution et utilise des politiques AWS Identity and Access Management (IAM) pour contrôler l'accès aux commandes en cours d'exécution dans un conteneur en cours d'exécution. Ceci est rendu possible par le montage lié des fichiers binaires du SSM Agent nécessaires dans le conteneur. L'Amazon ECS ou l' AWS Fargate agent est chargé de démarrer l'agent principal SSM dans le conteneur en même temps que le code de votre application. Pour plus d'informations, consultez Systems Manager Session Manager.

Vous pouvez vérifier quel utilisateur a accédé au conteneur à l'aide de l'ExecuteCommandévénement AWS CloudTrail et enregistrer chaque commande (et sa sortie) dans Amazon S3 ou Amazon CloudWatch Logs. Pour chiffrer les données entre le client local et le conteneur avec votre propre clé de chiffrement, vous devez fournir la clé AWS Key Management Service (AWS KMS).

Utilisation d'ECS Exec

Modifications facultatives de la définition de tâche

Si vous définissez le paramètre de définition de tâche initProcessEnabled surtrue, le processus d'initialisation démarre à l'intérieur du conteneur. Cela supprime tous les processus enfants de l'agent SSM zombie trouvés. Voici un exemple.

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

Activation d'ECS Exec pour vos tâches et services

Vous pouvez activer la fonctionnalité ECS Exec pour vos services et tâches autonomes en spécifiant l'--enable-execute-commandindicateur lorsque vous utilisez l'une des AWS CLI commandes suivantes : create-service, update-servicestart-task, ou. run-task

Par exemple, si vous exécutez la commande suivante, la fonctionnalité ECS Exec est activée pour un service nouvellement créé qui s'exécute sur Fargate. Pour plus d'informations sur la création de services, consultez 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

Après avoir activé ECS Exec pour une tâche, vous pouvez exécuter la commande suivante pour confirmer que la tâche est prête à être utilisée. Si la propriété lastStatus de ExecuteCommandAgent est répertoriée comme RUNNING et que la propriété enableExecuteCommand est définie sur true, alors votre tâche est prête.

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

L'extrait de sortie suivant est un exemple de ce que vous pouvez voir.

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

Exécution de commandes avec ECS Exec

Une fois que vous avez confirmé que ExecuteCommandAgent est en cours d'exécution, vous pouvez ouvrir un shell interactif sur votre conteneur à l'aide de la commande suivante. Si votre tâche contient plusieurs conteneurs, vous devez spécifier le nom du conteneur à l'aide de l'indicateur --container. Amazon ECS ne prend en charge que le lancement de sessions interactives. Vous devez donc utiliser l'indicateur --interactive.

La commande suivante exécutera une /bin/sh commande interactive sur un conteneur nommé container-name pour une tâche dont l'ID est task-id.

L'identifiant de tâche est l'Amazon Resource Name (ARN) de la tâche.

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

Journalisation à l'aide d'ECS Exec

Activer la connexion à vos tâches et services

Important

Pour plus d'informations sur la CloudWatch tarification, consultez la section CloudWatch Tarification. Amazon ECS propose également des métriques de surveillance sans coûts supplémentaires. Pour plus d’informations, consultez Surveillez Amazon ECS à l'aide de CloudWatch .

Amazon ECS fournit une configuration par défaut pour les commandes de journalisation exécutées à l'aide d'ECS Exec en envoyant des CloudWatch journaux à Logs à l'aide du pilote de awslogs journal configuré dans votre définition de tâche. Si vous souhaitez fournir une configuration personnalisée, l' AWS CLI prend en charge un indicateur --configuration pour les commandes create-cluster et update-cluster. Il est également important de savoir que l'image du conteneur nécessite script et doit être installée cat pour que les journaux de commandes soient correctement chargés sur Amazon S3 ou CloudWatch Logs. Pour de plus amples informations sur la création de clusters, consultez create-cluster.

Note

Cette configuration ne gère que la journalisation de la session execute-command. Cela n'affecte pas la journalisation de votre application.

L'exemple suivant crée un cluster, puis enregistre la sortie dans vos CloudWatch journaux LogGroup nommés cloudwatch-log-group-name et dans votre compartiment Amazon S3 nommés3-bucket-name.

Vous devez utiliser une clé gérée par le AWS KMS client pour chiffrer le groupe de journaux lorsque vous définissez l'CloudWatchEncryptionEnabledoption sur. true Pour plus d'informations sur le chiffrement du groupe de journaux, voir Chiffrer les données des CloudWatch journaux dans Logs using AWS Key Management Service, dans le Guide de l'Amazon CloudWatch Logs utilisateur.

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 \
        } \
    }"

La propriété logging détermine le comportement de la capacité de journalisation d'ECS Exec :

  • NONE: la journalisation est désactivée.

  • DEFAULT: les journaux sont envoyés au awslogs pilote configuré. Si le pilote n'est pas configuré, aucun journal n'est enregistré.

  • OVERRIDE: les journaux sont envoyés au compartiment Amazon CloudWatch Logs fourni LogGroup, au compartiment Amazon S3, ou aux deux.

Autorisations IAM requises pour Amazon CloudWatch Logs ou Amazon S3 Logging

Pour activer la journalisation, le rôle de tâche Amazon ECS référencé dans votre définition de tâche doit disposer d'autorisations supplémentaires. Ces autorisations supplémentaires peuvent être ajoutées en tant que stratégie au rôle de tâche. Ils sont différents selon que vous dirigez vos journaux vers Amazon CloudWatch Logs ou Amazon S3.

Amazon CloudWatch Logs

L'exemple de politique suivant ajoute les autorisations Amazon CloudWatch Logs requises.

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

L'exemple suivant de stratégie ajoute les autorisations Amazon S3 requises.

{
   "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/*"
        }
    ]
   }

Autorisations IAM requises pour le chiffrement à l'aide des vôtres AWS KMS key (clé KMS)

Par défaut, les données transférées entre votre client local et le conteneur utilisent le cryptage TLS 1.2 qui AWS fournit. Pour chiffrer davantage les données à l'aide de votre propre clé KMS, vous devez créer une clé KMS et ajouter l'autorisation kms:Decrypt à votre rôle IAM de tâche. Votre conteneur utilise cette autorisation pour déchiffrer les données. Pour plus d'informations sur la création d'une clé KMS, consultez Création de clés.

Vous ajoutez la politique intégrée suivante à votre rôle IAM de tâche qui nécessite les AWS KMS autorisations. Pour plus d’informations, consultez Autorisations ECS Exec.

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

Pour que les données soient chiffrées à l'aide de votre propre clé KMS, l'utilisateur ou le groupe utilisant l'action execute-command doit être accordée à l'autorisation kms:GenerateDataKey.

L'exemple de stratégie suivant pour votre utilisateur ou groupe contient l'autorisation requise pour utiliser votre propre clé KMS. Vous devez spécifier l'Amazon Resource Name (ARN) de votre clé KMS.

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

Utilisation de stratégies IAM pour limiter l'accès à ECS Exec

Vous limitez l'accès des utilisateurs à l'action de l'API d'exécution de commande en utilisant une ou plusieurs des clés de condition de politique IAM suivantes :

  • aws:ResourceTag/clusterTagKey

  • ecs:ResourceTag/clusterTagKey

  • aws:ResourceTag/taskTagKey

  • ecs:ResourceTag/taskTagKey

  • ecs:container-name

  • ecs:cluster

  • ecs:task

  • ecs:enable-execute-command

Avec l'exemple de stratégie IAM suivant, les utilisateurs peuvent exécuter des commandes dans des conteneurs qui s'exécutent dans des tâches avec une balise qui possède une clé environment et une valeur development, dans un cluster nommé 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"
                }
            }
        }
    ]
}

Avec l'exemple de politique IAM suivant, les utilisateurs ne peuvent pas utiliser l'API execute-command lorsque le nom du conteneur est production-app.

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

Avec la stratégie IAM suivante, les utilisateurs ne peuvent lancer des tâches que lorsque ECS Exec est désactivé.

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

Étant donné que l'action d'API execute-command contient uniquement des ressources de tâche et de cluster dans une reqûete, seules les balises de cluster et de tâche sont évaluées.

Pour plus d'informations sur les clés de condition de stratégie IAM, consultez Actions, ressources et clés de condition pour Amazon Elastic Container Service dans la Référence de l'autorisation de service.

Limitation de l'accès à l'action StartSession

Bien qu'il soit possible de démarrer des sessions SSM sur votre conteneur en dehors d'ECS Exec, cela pourrait entraîner la non-journalisation des sessions. Les sessions démarrées en dehors d'ECS Exec sont également comptabilisées dans le quota de session. Nous vous recommandons de limiter cet accès en refusant l'action ssm:start-session directement pour vos tâches Amazon ECS à l'aide d'une stratégie IAM. Vous pouvez refuser l'accès à toutes les tâches Amazon ECS ou à des tâches spécifiques en fonction des balises utilisées.

Voici un exemple de stratégie IAM qui refuse l'accès à l'action ssm:start-session pour les tâches dans toutes les régions avec un nom de cluster spécifié. Si vous le souhaitez, vous pouvez inclure un caractère générique avec l'option cluster-name.

{
    "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/*"
            ]
        }
    ]
}

Voici un exemple de stratégie IAM qui refuse l'accès à l'action ssm:start-session sur les ressources dans toutes les régions étiquetées avec la clé de balise Task-Tag-Key et la valeur de baliseExec-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"
                }
            }
        }
    ]
}

Pour obtenir de l'aide concernant les problèmes que vous pourriez rencontrer lors de l'utilisation d'Amazon ECS Exec, consultez la section Résolution des problèmes liés à Exec.