Monitore os contêineres do Amazon ECS com o ECS Exec - Amazon Elastic Container Service

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Monitore os contêineres do Amazon ECS com o ECS Exec

Com o Amazon ECS Exec, você pode interagir diretamente com contêineres sem precisar interagir primeiro com o sistema operacional do contêiner do host, abrir portas de entrada ou gerenciar chaves SSH. É possível usar o ECS Exec para executar comandos em ou obter um shell para um contêiner em execução em uma instância do Amazon EC2 ou no AWS Fargate. Isso facilita a coleta de informações de diagnóstico e a solução rápida de problemas. Por exemplo, em um contexto de desenvolvimento, você pode usar o ECS Exec para interagir facilmente com vários processos nos contêineres e solucionar problemas das aplicações. E em cenários de produção, você pode usá-lo para obter acesso rápido aos seus contêineres para depurar problemas.

Você pode executar comandos em um contêiner Linux ou Windows em execução usando o ECS Exec da API do Amazon ECS, AWS Command Line Interface (AWS CLI), AWS SDKs ou da CLI do Copilot. AWS Para obter detalhes sobre o uso do ECS Exec, bem como um vídeo passo a passo, usando a AWS CLI do Copilot, consulte a documentação do Copilot. GitHub

Também é possível usar o ECS Exec para manter políticas de controle de acesso mais rígidas e auditar o acesso ao contêiner. Ao ativar seletivamente esse recurso, você pode controlar quem pode executar comandos e em quais tarefas eles podem executar estes comandos. Com um registro de cada comando e sua saída, você pode usar o ECS Exec para auditar quais tarefas foram executadas e você pode usar CloudTrail para auditar quem acessou um contêiner.

Considerações para usar o ECS Exec

Para este tópico, você deve se familiarizar com os seguintes aspectos envolvidos com o uso do ECS Exec:

  • Atualmente, o ECS Exec não é suportado usando o. AWS Management Console

  • Há suporte para o ECS Exec para tarefas executadas na infraestrutura a seguir:

    • Contêineres Linux no Amazon EC2 em qualquer AMI otimizada para Amazon ECS, incluindo Bottlerocket

    • Contêineres Linux e Windows em instâncias externas (Amazon ECS Anywhere)

    • Contêineres Linux e Windows no AWS Fargate

    • Contêineres Windows no Amazon EC2 nas AMIs otimizadas para Amazon ECS do Windows (com a versão do agente de contêiner 1.56 ou posterior):

      • AMI do Windows Server 2022 Full otimizada para Amazon ECS

      • AMI do Windows Server 2022 Core otimizada para Amazon ECS

      • AMI do Windows Server 2019 Full otimizada para Amazon ECS

      • AMI do Windows Server 2019 Core otimizada para Amazon ECS

      • AMI do Windows Server 20H2 Core otimizada para Amazon ECS

  • ECS Exec e Amazon VPC

    • Se você estiver usando endpoints da Amazon VPC de interface com o Amazon ECS, deverá criar os endpoints da Amazon VPC da interface para o Gerenciador de Sessões do Systems Manager (ssmmessages). Para obter mais informações sobre os endpoints VPC do Systems Manager, consulte Usar AWS PrivateLink para configurar um VPC endpoint para o Session Manager no Guia do usuário.AWS Systems Manager

    • Se você estiver usando endpoints do Amazon VPC de interface com o Amazon ECS e estiver usando o AWS KMS key para criptografia, deverá criar o endpoint do Amazon VPC da interface para o AWS KMS key. Para obter mais informações, consulte Conexão com o AWS KMS key usando um endpoint da VPC no Guia do desenvolvedor do AWS Key Management Service .

    • Quando você tem tarefas executadas em instâncias do Amazon EC2, use o modo awsvpc de rede. Se você não tem acesso à Internet (por exemplo, não está configurado para usar um gateway NAT), você deve criar a interface Amazon VPC endpoints para o Systems Manager Session Manager (). ssmmessages Para obter mais informações sobre considerações a respeito do modo de rede awsvpc, consulte Considerações. Para obter mais informações sobre os endpoints VPC do Systems Manager, consulte Usar AWS PrivateLink para configurar um VPC endpoint para o Session Manager no Guia do usuário.AWS Systems Manager

  • ECS Exec e SSM

    • Quando um usuário executa comandos em um contêiner usando o ECS Exec, estes comandos são executados como o usuário root. O SSM Agent e seus processos filho são executados como raiz mesmo quando você especifica um ID de usuário para o contêiner.

    • O agente SSM exige que o sistema de arquivos do contêiner possa ser gravado para criar os diretórios e arquivos necessários. Portanto, não existe suporte para a ação de tornar o sistema de arquivos raiz somente leitura usando o parâmetro de definição de tarefa readonlyRootFilesystem ou qualquer outro método.

    • Embora iniciar sessões do SSM fora da ação execute-command seja possível, isso fará com que as sessões não sejam registradas e contadas em relação ao limite da sessão. Recomendamos limitar esse acesso ao negar a ação ssm:start-session usando uma política do IAM. Para ter mais informações, consulte Limitar o acesso à ação Iniciar sessão.

  • Os recursos a seguir são executados como um contêiner auxiliar. Portanto, você deve especificar o nome do contêiner no qual executar o comando.

    • Monitoramento de runtime

    • Service Connect

  • Os usuários podem executar todos os comandos disponíveis no contexto do contêiner. As seguintes ações podem resultar em processos órfãos e zumbis: encerramento do processo principal do contêiner, encerramento do agente de comando e exclusão de dependências. Para limpar os processos zumbis, recomendamos a adição do sinalizador initProcessEnabled à definição da tarefa.

  • O ECS Exec usa um pouco de CPU e memória. Recomendamos que isso seja previsto quando você especificar as alocações de recursos de CPU e memória na definição da tarefa.

  • Você deve estar usando a AWS CLI versão 1.22.3 ou posterior ou a AWS CLI versão 2.3.6 ou posterior. Para obter informações sobre como atualizar o AWS CLI, consulte Instalando ou atualizando a versão mais recente do AWS CLI no Guia do AWS Command Line Interface Usuário, Versão 2.

  • É possível ter somente uma sessão do ECS Exec por namespace de ID de processo (PID). Se você estiver compartilhando um namespace de PID em uma tarefa, só poderá iniciar sessões do ECS Exec em um contêiner.

  • A sessão do ECS Exec tem um tempo limite de ociosidade de 20 minutos. Esse valor não pode ser alterado.

  • Não é possível ativar o ECS Exec para tarefas existentes. Ele só pode ser ativado para novas tarefas.

  • Você não pode usar o ECS Exec run-task ao iniciar uma tarefa em um cluster que usa escalabilidade gerenciada com posicionamento assíncrono (iniciar uma tarefa sem instância).

  • Você não pode executar o ECS Exec em contêineres do Microsoft Nano Server. Para obter mais informações sobre os contêineres do Nano Server, consulte Nano Server no site do Docker.

Pré-requisitos para usar o ECS Exec

Antes de começar a usar o ECS Exec, certifique-se de ter concluído estas ações:

  • Instale e configure a AWS CLI. Para ter mais informações, consulte AWS CLI.

  • Instale o plug-in do Session Manager para AWS CLI o. Para obter mais informações, consulte Instalar o plugin do gerenciador de sessão para a AWS CLI.

  • Você deve usar um perfil de tarefa com as permissões apropriadas para o ECS Exec. Para obter mais informações, consulte Perfil do IAM de tarefa.

  • O ECS Exec tem requisitos de versão que dependem das suas tarefas estarem hospedadas no Amazon EC2 ou no AWS Fargate:

    • Se você estiver usando o Amazon EC2, deverá usar uma AMI otimizada para Amazon ECS que tenha sido lançada após 20 de janeiro de 2021, com a versão 1.50.2 ou superior do agente. Para obter mais informações consulte AMIs otimizadas para Amazon ECS.

    • Se você estiver usando AWS Fargate, deverá usar a versão da plataforma 1.4.0 ou superior (Linux) ou 1.0.0 (Windows). Para obter mais informações, consulte Versões da plataforma do AWS Fargate.

Arquitetura

O ECS Exec usa o AWS Systems Manager (SSM) Session Manager para estabelecer uma conexão com o contêiner em execução e usa políticas AWS Identity and Access Management (IAM) para controlar o acesso aos comandos em execução em um contêiner em execução. Isso é possível por meio de uma montagem bind dos binários necessários do SSM Agent no contêiner. O Amazon ECS ou AWS Fargate agente é responsável por iniciar o agente principal do SSM dentro do contêiner junto com o código do seu aplicativo. Para ter mais informações, consulte o Systems Manager Session Manager.

Você pode auditar qual usuário acessou o contêiner usando o ExecuteCommand evento AWS CloudTrail e registrar cada comando (e sua saída) no Amazon S3 ou no Amazon CloudWatch Logs. Para criptografar dados entre o cliente local e o contêiner com sua própria chave de criptografia, você deve fornecer a chave AWS Key Management Service (AWS KMS).

Usar o ECS Exec

Alterações opcionais de definição de tarefa

Se você definir o parâmetro de definição da tarefa initProcessEnabled comotrue, isso iniciará o processo de inicialização dentro do contêiner. Isso remove todos os processos secundários do agente SSM zumbi encontrados. A seguir, é fornecido um exemplo.

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

Ativar o ECS Exec para tarefas e serviços

Você pode ativar o recurso ECS Exec para seus serviços e tarefas autônomas especificando o --enable-execute-command sinalizador ao usar um dos seguintes AWS CLI comandos: create-service,,, update-serviceou. start-taskrun-task

Por exemplo, se você executar o comando a seguir, o recurso ECS Exec será ativado para um serviço recém-criado que é executado no Fargate. Para obter mais informações sobre como criar serviços, consulte 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

Depois de ativar o ECS Exec para uma tarefa, execute o comando a seguir para confirmar se a tarefa está pronta para ser usada. Se a propriedade lastStatus do ExecuteCommandAgent estiver listada como RUNNING e a propriedade enableExecuteCommand estiver definida como true, a tarefa estará pronta.

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

O seguinte trecho de saída é um exemplo do que pode ser visualizado.

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

Executar comandos usando ECS Exec

Depois de ter confirmado que o ExecuteCommandAgent está em execução, você pode abrir um shell interativo no contêiner usando o comando a seguir. Se a tarefa contiver vários contêineres, você deverá especificar o nome do contêiner usando o sinalizador --container. O Amazon ECS só oferece suporte à inicialização de sessões interativas Portanto, você deve usar o sinalizador --interactive.

O comando a seguir executará um /bin/sh comando interativo em um contêiner chamado container-name para uma tarefa com um ID de task-id.

O ID da tarefa é o Amazon Resource Name (ARN) da tarefa.

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

Registrar e auditar usando ECS Exec

Ativar registro e auditoria nas tarefas e serviços

Importante

Para obter mais informações sobre CloudWatch preços, consulte CloudWatch Preços. O Amazon ECS também fornece métricas de monitoramento, fornecidas sem custo adicional. Para ter mais informações, consulte Monitore o Amazon ECS usando CloudWatch .

O Amazon ECS fornece uma configuração padrão para comandos de registro executados usando o ECS Exec enviando CloudWatch registros para Logs usando o driver de awslogs log que está configurado na sua definição de tarefa. Se você quiser fornecer uma configuração personalizada, a AWS CLI oferecerá suporte ao sinalizador --configuration para os comandos create-cluster e update-cluster. Também é importante saber que a imagem do contêiner precisa script ser instalada cat para que os registros de comando sejam carregados corretamente no Amazon S3 ou CloudWatch no Logs. Para obter mais informações sobre como criar clusters, consulte create-cluster.

nota

Essa configuração só lida com o registro da sessão execute-command. Isso não afeta o registro da aplicação.

O exemplo a seguir cria um cluster e, em seguida, registra a saída em seus CloudWatch Logs LogGroup nomeados cloudwatch-log-group-name e em seu bucket Amazon S3 nomeado. s3-bucket-name

Você deve usar uma chave gerenciada pelo AWS KMS cliente para criptografar o grupo de registros ao definir a CloudWatchEncryptionEnabled true opção como. Para obter informações sobre como criptografar o grupo de registros, consulte Criptografar dados de registro em CloudWatch registros usando AWS Key Management Service, no Guia do Amazon CloudWatch Logs usuário.

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

A propriedade logging determina o comportamento da capacidade de registro do ECS Exec:

  • NONE: o registro está desativado.

  • DEFAULT: os registros são enviados para o awslogs driver configurado. Se o driver não estiver configurado, nenhum registro será salvo.

  • OVERRIDE: os registros são enviados para o Amazon CloudWatch Logs fornecido LogGroup, para o bucket Amazon S3 ou para ambos.

Permissões do IAM necessárias para Amazon CloudWatch Logs ou Amazon S3 Logging

Para ativar o registro, a função de tarefa do Amazon ECS referenciada na definição de tarefa precisa ter permissões adicionais. Essas permissões adicionais podem ser acrescentadas como uma política para o perfil de tarefa. Eles são diferentes dependendo se você direciona seus registros para o Amazon CloudWatch Logs ou o Amazon S3.

Amazon CloudWatch Logs

O exemplo de política a seguir adiciona as permissões necessárias do Amazon CloudWatch Logs.

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

O exemplo de política a seguir adiciona as permissões necessárias do Amazon S3.

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

Permissões do IAM necessárias para criptografia usando suas próprias AWS KMS key (chave KMS)

Por padrão, os dados transferidos entre seu cliente local e o contêiner usam a criptografia TLS 1.2 que AWS fornece. Para criptografar ainda mais os dados usando sua própria chave do KMS, crie uma chave do KMS e adicione a permissão kms:Decrypt à função do IAM da tarefa. Essa permissão é usada pelo contêiner para descriptografar os dados. Para obter mais informações sobre a criação de uma chave do KMS, consulte Criar chaves.

Você adiciona a seguinte política embutida à sua função do IAM de tarefa, que requer as AWS KMS permissões. Para ter mais informações, consulte Permissões do IAM necessárias para o ECS Exec.

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

Para que os dados sejam criptografados com a própria chave do KMS, o usuário ou grupo que está usando a ação execute-command deve receber a permissão kms:GenerateDataKey.

O exemplo de política a seguir para o usuário ou grupo contém a permissão necessária pra o uso da própria chave do KMS. É necessário especificar o nome do recurso da Amazon (ARN) da chave do KMS.

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

Uso de políticas do IAM para limitar o acesso ao ECS Exec

Você limita o acesso do usuário à ação da API execute-command usando uma ou mais das seguintes chaves de condição da política do IAM:

  • aws:ResourceTag/clusterTagKey

  • ecs:ResourceTag/clusterTagKey

  • aws:ResourceTag/taskTagKey

  • ecs:ResourceTag/taskTagKey

  • ecs:container-name

  • ecs:cluster

  • ecs:task

  • ecs:enable-execute-command

Com o exemplo de política do IAM a seguir, os usuários podem executar comandos em contêineres que estão sendo executados em tarefas com uma etiqueta que tenha a chave environment e o valor development em um cluster denominado 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" } } } ] }

Com o exemplo de política do IAM a seguir, os usuários não podem usar a API execute-command quando o nome do contêiner é production-app.

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

Com a seguinte política do IAM, os usuários só podem iniciar tarefas quando o ECS Exec estiver desativado.

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

Como ação da API execute-command contém apenas recursos de tarefa e cluster em uma solicitação, somente etiquetas de cluster e tarefa são avaliadas.

Para obter mais informações sobre essas chaves de condição de política do IAM, consulte Ações, recursos e chaves de condição do Amazon Elastic Container Service na Referência de autorização do serviço.

Limitar o acesso à ação Iniciar sessão

Embora seja possível iniciar sessões do SSM no contêiner fora do ECS Exec, isso poderá fazer com que as sessões não sejam registradas. As sessões iniciadas fora do ECS Exec também são consideradas na cota de sessão. Recomendamos que esse acesso seja limitado negando diretamente a ação ssm:start-session para as tarefas do Amazon ECS que usam uma política do IAM. É possível negar acesso a todas as tarefas do Amazon ECS ou a tarefas específicas com base nas etiquetas usadas.

Veja a seguir um exemplo de política do IAM que nega acesso à ação ssm:start-session para tarefas em todas as regiões com um nome de cluster especificado. Opcionalmente, é possível incluir um curinga com o 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/*" ] } ] }

Veja a seguir um exemplo de política do IAM que nega acesso à ação ssm:start-session em recursos em todas as regiões marcadas com chave de etiqueta Task-Tag-Key e valor de etiqueta 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" } } } ] }

Para obter ajuda com quaisquer problemas que você possa encontrar ao usar o Amazon ECS Exec, consulte Solução de problemas com o Exec.