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.

Surveillance des 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 obtenir un accès d’urgence à vos conteneurs afin de déboguer 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 depuis l'API Amazon ECS, AWS Command Line Interface (AWS CLI), AWS SDK, ou AWS Interface de ligne de commande Copilote. Pour plus de détails sur l'utilisation d'ECS Exec, ainsi qu'une présentation vidéo, utilisez AWS Interface de ligne de commande Copilot, consultez le Copilote GitHub documentation.

Vous pouvez également utiliser ECS Exec pour appliquer 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 leur sortie, vous pouvez utiliser ECS Exec pour voir quelles tâches ont été exécutées et vous pouvez utiliser CloudTrail pour vérifier qui a accédé à un conteneur.

Considérations

Tenez compte des éléments suivants lorsque vous utilisez ECS Exec :

Architecture

ECS Exec utilise AWS Systems Manager (SSM) Session Manager pour établir une connexion avec le conteneur en cours d'exécution et utilise Gestion des identités et des accès AWS politiques (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 AWS Fargate l'agent est chargé de démarrer l'agent principal SSM à l'intérieur du conteneur à côté du 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 du ExecuteCommand événement en AWS CloudTrail et enregistrez chaque commande (et son résultat) sur Amazon S3 ou Amazon CloudWatch Journaux. Pour chiffrer les données entre le client local et le conteneur à l'aide de votre propre clé de chiffrement, vous devez fournir le AWS Key Management Service (AWS KMS) clé.

Configuration d’ECS Exec

Pour utiliser ECS Exec, vous devez d’abord activer la fonctionnalité pour vos tâches et services. Vous pouvez ensuite exécuter des commandes dans vos conteneurs.

Modifications facultatives de la définition de tâche

Si vous définissez le paramètre de définition de tâche initProcessEnabled sur true, le processus init 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 fonction ECS Exec pour vos services et vos tâches autonomes en spécifiant --enable-execute-command drapeau lors de l'utilisation de l'un des indicateurs suivants AWS CLI commandes : create-service, update-service, start-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éé. 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

Journalisation à l’aide d’ECS Exec

Vous pouvez configurer la journalisation des sessions ECS Exec afin de capturer les commandes et leur sortie à des fins d’audit et de résolution des problèmes.

Activation de la journalisation et de l’audit dans vos tâches et services

Amazon ECS fournit une configuration par défaut pour les commandes de journalisation exécutées à l’aide d’ECS Exec. Par défaut, les journaux sont envoyés à CloudWatch Journaux à l'aide du awslogs pilote de journal configuré dans votre définition de tâche. Si vous souhaitez fournir une configuration personnalisée, AWS CLI prend en charge un --configuration drapeau pour les deux create-cluster et update-cluster commandes. L'image du conteneur nécessite script et cat à installer afin que les journaux de commandes soient chargés correctement sur Amazon S3 ou CloudWatch Journaux. Pour de plus amples informations sur la création de clusters, consultez create-cluster.

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

Vous devez utiliser un AWS KMS clé gérée par le client pour chiffrer le groupe de journaux lorsque vous définissez CloudWatchEncryptionEnabled option pour true. Pour plus d'informations sur le chiffrement du groupe de journaux, consultez Chiffrez les données du journal dans CloudWatch Journaux utilisant AWS Key Management Service, dans le Amazon CloudWatch Logs Guide de l'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 :

Autorisations IAM requises pour Amazon CloudWatch Journaux pour 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 ou non vos journaux vers Amazon CloudWatch Logs pour Amazon S3.

Amazon CloudWatch Logs

L'exemple de politique suivant ajoute l'Amazon requis CloudWatch Enregistre les autorisations.

{
   "Version":"2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
               "logs:CreateLogStream",
               "logs:DescribeLogStreams",
               "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:us-east-1:111122223333: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 en ligne suivante à votre rôle IAM de tâche qui nécessite les autorisations AWS KMS . Pour plus d’informations, consultez Autorisations ECS Exec.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
        }
    ]
}

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.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
        }
    ]
}

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

Vous limitez l’accès utilisateur à l’action d’API execute-command en utilisant une ou plusieurs des clés de condition de politique IAM suivantes :

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.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:ExecuteCommand",
                "ecs:DescribeTasks"
            ],
            "Resource": [
                   "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*",
                   "arn:aws:ecs:us-east-1:111122223333:cluster/cluster-name"
            ],
            "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.

JSON

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

JSON

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

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.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": [
                   "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*"
            ]
        }
    ]
}

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.

JSON

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

Résolution des problèmes ECS Exec

Pour aller plus loin dans la résolution, consultez la section Résolution des problèmes avec Exec.