Supervisión de los contenedores de Amazon ECS con ECS Exec

Con Amazon ECS Exec, puede interactuar directamente con los contenedores sin necesidad de interactuar primero con el sistema operativo del contenedor host, abrir puertos entrantes o administrar claves SSH. Puede utilizar ECS Exec para ejecutar comandos en un contenedor u obtener un shell en un contenedor que se ejecute en una instancia de Amazon EC2 o en AWS Fargate. Esto facilita la recopilación de información de diagnóstico y la rápida resolución de problemas. Por ejemplo, en un contexto de desarrollo, puede utilizar ECS Exec para interactuar fácilmente con varios procesos de los contenedores y solucionar problemas de las aplicaciones. Y, en escenarios de producción, puede utilizarlo para obtener acceso a los contenedores con el fin de depurar problemas.

Para ejecutar comandos en un contenedor de Linux o Windows en ejecución, puede utilizar ECS Exec desde la API de Amazon ECS, la AWS Command Line Interface (AWS CLI), el SDK de AWS o la CLI de AWS Copilot. Para obtener más información acerca del uso de ECS Exec, así como una explicación en video de cómo se utiliza la CLI de AWS Copilot, consulte la Documentación de GitHub sobre Copilot.

ECS Exec también se puede utilizar para mantener políticas de control de acceso más estrictas. Al activar selectivamente esta función, puede controlar quiénes puede ejecutar comandos y en qué tareas pueden hacerlo. Con un registro de cada comando y su salida, puede utilizar ECS Exec para ver qué tareas se ejecutaron y CloudTrail para auditar quiénes accedieron a un contenedor.

Consideraciones

Para este tema, debería estar familiarizado con los siguientes aspectos relacionados con la utilización de ECS Exec:

Requisitos previos

Antes de comenzar a utilizar ECS Exec, asegúrese de haber completado estas acciones:

Arquitectura

ECS Exec utiliza AWS Systems Manager Session Manager (SSM) para establecer una conexión con el contenedor en ejecución y las políticas de AWS Identity and Access Management (IAM) para controlar el acceso a comandos en ejecución en un contenedor en ejecución. Esto se logra mediante el montaje vinculado de los binarios de SSM Agent necesarios en el contenedor. El agente de Amazon ECS o de AWS Fargate es responsable de iniciar el agente principal de SSM dentro del contenedor junto con el código de la aplicación. Para obtener más información, consulte Systems Manager Session Manager.

Puede auditar qué usuarios accedieron al contenedor mediante el evento ExecuteCommand en AWS CloudTrail y registrar cada comando (y su resultado) en Amazon S3 o en los registros de Amazon CloudWatch. Para cifrar datos entre el cliente local y el contenedor con su propia clave de cifrado, debe proporcionar la clave de AWS Key Management Service (AWS KMS).

Uso de ECS Exec

Cambios opcionales en la definición de tareas

Si establece el parámetro de definición de tareas initProcessEnabled en true, se inicia el proceso de inicio dentro del contenedor. Esto elimina cualquier proceso secundario zombi del agente de SSM encontrado. A continuación, puede ver un ejemplo.

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

Activación de ECS Exec para las tareas y los servicios

Para activar la característica ECS Exec para los servicios y las tareas independientes, puede especificar el indicador --enable-execute-command cuando se utiliza uno de los siguientes comandos de la AWS CLI: create-service, update-service, start-task o run-task.

Por ejemplo, si ejecuta el siguiente comando, la característica ECS Exec se activa para un servicio recién creado que se ejecuta en Fargate. Para obtener más información acerca de la creación de servicios, 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

Después de activar ECS Exec para una tarea, puede ejecutar el siguiente comando para confirmar que la tarea está lista para utilizarse. Si la propiedad lastStatus del ExecuteCommandAgent se aparece como RUNNING y la propiedad enableExecuteCommandse establece en true, su tarea está lista.

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

El siguiente fragmento de código resultante es un ejemplo de lo que puede ver.

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

Ejecución de comandos mediante ECS Exec

Después de confirmar que ExecuteCommandAgent se está ejecutando, puede abrir un shell interactivo en el contenedor mediante el siguiente comando. Si la tarea contiene varios contenedores, debe especificar el nombre del contenedor mediante el indicador --container. Amazon ECS solo admite la iniciación de sesiones interactivas, por lo que debe utilizar el indicador --interactive.

El siguiente comando ejecutará un comando /bin/sh interactivo en un contenedor denominado container-name para una tarea con un ID de task-id.

El task-id es el nombre de recurso de Amazon (ARN) de la tarea.

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

Registro mediante ECS Exec

Activación del registro en las tareas y los servicios

Amazon ECS proporciona una configuración predeterminada para los comandos de registro que se ejecutan a través de ECS Exec mediante el envío de registros a CloudWatch Logs a través del controlador de registros awslogs configurado en la definición de tareas. Si desea utilizar una configuración personalizada, la AWS CLI admite un indicador --configuration para los comandos create-cluster y update-cluster. También es importante saber que la imagen de contenedor requiere la instalación de script y cat para que los registros de comandos se carguen correctamente en los registros de Amazon S3 o CloudWatch Logs. Para obtener más información acerca de cómo crear clústeres, consulte create-cluster.

En el ejemplo siguiente, se crea un clúster y, a continuación, se registra el resultado en el LogGroup del registro de CloudWatch con el nombre cloudwatch-log-group-name y en el bucket de Amazon S3 con el nombre s3-bucket-name.

Debe utilizar una clave AWS KMS administrada por el cliente para cifrar el grupo de registro cuando establece la opción CloudWatchEncryptionEnabled en true. Para obtener información acerca de cómo cifrar el grupo de registros, consulte Cifrado de datos de registro en CloudWatch Logs mediante AWS Key Management Service en la Guía del usuario de Amazon CloudWatch Logs.

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 propiedad logging determina el comportamiento de la capacidad de registro de ECS Exec:

Se requieren permisos de IAM para generar registros en Amazon CloudWatch Logs o Amazon S3

Para habilitar el registro, el rol de tareas de Amazon ECS al que se hace referencia en la definición de tareas debe tener permisos adicionales. Estos permisos adicionales se pueden agregar como política al rol de tareas. Difieren en función de si dirige sus registros a Registros de Amazon CloudWatch o a Amazon S3.

Amazon CloudWatch Logs

La siguiente política de ejemplo agrega los permisos de Registros de Amazon CloudWatch requeridos.

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

La siguiente política de ejemplo agrega los permisos de Amazon S3 requeridos.

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

Permisos de IAM requeridos para el cifrado con su propia AWS KMS key (clave de KMS)

De forma predeterminada, los datos transferidos entre el cliente local y el contenedor utilizan el cifrado TLS 1.2 que proporciona AWS. Para cifrar aún más los datos con su propia clave de KMS, debe crear una clave deKMS y agregar el permiso kms:Decrypt al rol de IAM para tareas. El contenedor utiliza este permiso para descifrar los datos. Para obtener más información acerca de cómo crear una clave de KMS, consulte Creación de claves.

Agregue la siguiente política insertada al rol de IAM para tareas que requiere los permisos de AWS KMS. Para obtener más información, consulte Permisos de ECS Exec.

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

Para que los datos se cifren con su propia clave de KMS, se debe conceder al usuario o el grupo que utiliza la acción execute-command el permiso kms:GenerateDataKey.

La siguiente política de ejemplo para su usuario o grupo contiene el permiso requerido para utilizar su propia clave de KMS. Debe especificar el nombre de recurso de Amazon (ARN) de la clave de KMS.

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

Utilización de políticas de IAM para limitar el acceso a ECS Exec

Limite el acceso de los usuarios a la acción de la API execute-command mediante una o varias de las siguientes claves de condición de la política de IAM:

Con la siguiente política de IAM de ejemplo, los usuarios pueden ejecutar comandos en contenedores que se ejecutan dentro de tareas con una etiqueta que contiene una clave environment y un valor development, y en un clúster con el nombre 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"
                }
            }
        }
    ]
}

Con la siguiente política de IAM de ejemplo, los usuarios no pueden utilizar la API execute-command cuando el nombre del contenedor es production-app.

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

Con la siguiente política de IAM, los usuarios solo pueden lanzar tareas cuando ECS Exec está desactivado.

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

Para obtener más información acerca de las claves de condición de la política de IAM, consulte Acciones, recursos y claves de condición de Amazon Elastic Container Service en la Referencia de autorizaciones de servicio.

Limitación del acceso a la acción Iniciar sesión

Si bien es posible iniciar sesiones de SSM en el contenedor fuera de ECS Exec, esto podría provocar que las sesiones no se registraran. Las sesiones iniciadas fuera de ECS Exec también cuentan para la cuota de sesiones. Recomendamos limitar este acceso directamente mediante la denegación de la acción ssm:start-session para las tareas de Amazon ECS que utilizan una política de IAM. Según las etiquetas que utilice, puede denegar el acceso a todas las tareas de Amazon ECS o a tareas específicas.

A continuación, se muestra una política de IAM de ejemplo que deniega el acceso a la acción ssm:start-session para las tareas de todas las regiones con un nombre de clúster especificado. Si lo desea, puede incluir un comodín con el 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/*"
            ]
        }
    ]
}

A continuación, se muestra una política de IAM de ejemplo que deniega el acceso a la acción ssm:start-session sobre recursos en todas las regiones etiquetadas con clave de etiqueta Task-Tag-Key y el 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 obtener ayuda con cualquier problema que pueda surgir al utilizar Amazon ECS Exec, consulte Troubleshooting issues with Exec.