Amazon ECS Exec Checker

The check-ecs-exec.sh script allows you to check and validate both your CLI environment and ECS cluster/task are ready for ECS Exec, by calling various AWS APIs on behalf of you. You can learn more about ECS Exec on the containers blog post and the official developer guide.

Prerequisites

The check-ecs-exec.sh requires the following commands.

jq
AWS CLI v1.19.28/v2.1.30 or later

Usage

$ ./check-ecs-exec.sh <YOUR_ECS_CLUSTER_NAME> <YOUR_ECS_TASK_ID>

Example 1 - Run without cloning Git repo

The check-ecs-exec.sh will use your default AWS CLI profile and the AWS region.

$ bash <( curl -Ls https://raw.githubusercontent.com/aws-containers/amazon-ecs-exec-checker/main/check-ecs-exec.sh ) <YOUR_ECS_CLUSTER_NAME> <YOUR_ECS_TASK_ID>

Example 2 - With AWS_* variables

The check-ecs-exec.sh will use the myprofile AWS CLI profile and us-west-2 AWS region.

$ export AWS_PROFILE=myprofile
$ export AWS_REGION=us-west-2

$ bash <( curl -Ls https://raw.githubusercontent.com/aws-containers/amazon-ecs-exec-checker/main/check-ecs-exec.sh ) <YOUR_ECS_CLUSTER_NAME> <YOUR_ECS_TASK_ID>

Example 3 - With MFA

The check-ecs-exec.sh automatically detects your MFA configuration for the AWS CLI. But you can also explicitly specify which MFA device to use by setting the ARN of the MFA device to AWS_MFA_SERIAL environment variable.

Example 4 - Switch AWS CLI binaries

If you have multiple AWS CLI installations in your environment, both AWS CLI v1 and v2 for example, you can choose which AWS CLI binary to use by passing the AWS_CLI_BIN env variable.

$ AWS_CLI_BIN=aws-v1 ./check-ecs-exec.sh <YOUR_ECS_CLUSTER_NAME> <YOUR_ECS_TASK_ID>

Checks

The check-ecs-exec.sh shows the results with three text colors, 🟢(Green), 🟡(Yellow), and 🔴(Red). Each color tells how you'll handle the results.

🟢(Green) - The configuration or the status is okay.
🟡(Yellow) - The configuration or the status should or would be recommended to fix, but you can use ECS Exec without fixing them.
🔴(Red) - You need to fix those results before using ECS Exec.

In the following screenshot for instance, we need to install the Session Manager plugin and give required permissions to the task role at least, but we can ignore the audit-logging configuration.

Note that it shows "SSM PrivateLink" at the bottom as a 🟡(yellow) result, but it can be a 🔴(red) result if your ECS task doesn't have proper outbound internet connectivity. In this case, you will need to configure an SSM PrivateLink in your VPC.

Reference - How to handle 🔴(Red) and 🟡(Yellow) items

🔴 Pre-flight check failed: jq command is missing
Install the jq command. See the official documentation for the details and how to install.
🔴 Pre-flight check failed: aws command is missing
Install the latest AWS CLI. See the official documentation for the AWS CLI v2 or the official documentation for the AWS CLI v1 for the details and how to install.
🔴 Pre-flight check failed: ECS Exec requires the AWS CLI v1.19.28/v2.1.30 or later
Upgrade to the latest AWS CLI. See the official documentation for the AWS CLI v2 or the official documentation for the AWS CLI v1 for the details and how to upgrade.
🔴 Session Manager Plugin | Missing
Install the Session Manager plugin. See the official documentation for the details and how to install.
🟡 Cluster Configuration | Audit Logging Not Configured / Disabled This check item won't block you to use ECS Exec, but we recommend you to enable logging and auditing for your ECS cluster from the security perspective. See the official documentation for the details and how to enable them.
🔴 Can I ExecuteCommand? | ecs:ExecuteCommand: implicitDeny
The IAM user/role you used for the check-ecs-exec.sh are not allowed to use the ecs:ExecuteCommand API. See the "Using IAM policies to limit access to ECS Exec section in the official documentation to add the required permission to the IAM user/role.
Note that the Condition element of the IAM policy is not currently supported to evaluate by check-ecs-exec.sh.
🔴 Can I ExecuteCommand? | kms:GenerateDataKey: implicitDeny
The IAM user/role you used for the check-ecs-exec.sh are not allowed to use the kms:GenerateDataKey API with the given KMS Key ID which you're using for the logging and auditing configuration for ECS exec. See the "IAM permissions required for encryption using your own KMS customer master key (CMK) section under the "Logging and Auditing using ECS Exec" section in the official documentation to add the required permission to the IAM user/role.
Note that the Condition element of the IAM policy is not currently supported to evaluate by check-ecs-exec.sh.
🟡 Can I ExecuteCommand? | ssm:StartSession denied?: allowed
The result means your IAM user/role is allowed to do ssm:StartSession action to the ECS task. This check item won't block you to use ECS Exec, but we recommend you to limit access to the ssm:StartSession API, from the security and the principle of least privilege perspectives. See the ECS official documentation for further details.
Note that the Condition element of the IAM policy is not currently supported to evaluate by check-ecs-exec.sh.
🔴 Task Status | DEACTIVATING or STOPPING or DEPROVISIONING or STOPPED
Your ECS task has already stopped, or is shutting down. ECS Exec requires the task is in the RUNNING state. Restart your ECS task if it's a standalone task, or wait for another task if it's a part of an ECS service. See also the Task lifecycle in the ECS documentation for more details.
🟡 Task Status | PROVISIONING or ACTIVATING or PENDING
Your ECS task is in the middle of its starting process. ECS Exec requires the task is in the RUNNING state. Wait few more seconds for the task to be ready. See also the Task lifecycle in the ECS documentation for more details.
🔴 Platform Version | 1.3.0 (Required: >= 1.4.0)
On AWS Fargate, ECS Exec requires the Platform version 1.4.0 or higher (Linux) or 1.0.0 (Windows). If your ECS task is part of an ECS service, then you can update the platform version by specifying the PlatformVersion parameter for the UpdateService API. If your ECS task is a standalone task, then you need to re-run the ECS task with the PlatformVersion parameter specified for the RunTask API. See also the migration guide from the previous PVs.
🔴 ECS Agent Version | x.y.z (Required: >= 1.50.2)
You need to update the version of the ECS Container Agent for your EC2 instance where your ECS task runs. See the ECS official documentation for the details and how to update.
🔴 Exec Enabled for Task | NO
You need to enable the ECS Exec feature for your ECS service or your ECS standalone task. If your ECS task is part of an ECS service, then you can update the ECS by specifying the EnableExecuteCommand parameter for the UpdateService API. If your ECS task is a standalone task, then you need to re-run the ECS task with the EnableExecuteCommand parameter specified for the RunTask API.
🔴 Managed Agent Status | STOPPED (Reason: stopped-reason-here)
The managed agent for a container in your Task has stopped for some reasons. If you see this error again and again even after re-running your ECS task, then make sure you have other results from check-ecs-exec.sh are all green.
🟡 Init Process Enabled | Disabled
This check item won't block you to use ECS Exec, but we recommend you to add the initProcessEnabled flag to your ECS task definition for each container to avoid having orphaned and zombie processes. See the "Considerations for using ECS Exec" in the ECS official documentation for more details.
🔴 Read-Only Root Filesystem | ReadOnly
ECS Exec uses the SSM agent as its managed agent, and the agents requires that the container file system is able to be written in order to create the required directories and files. Therefore, you need to set the readonlyRootFilesystem flag as false in your task definition to exec into the container using ECS Exec. See the "Considerations for using ECS Exec" in the ECS official documentation for more details.
🔴 EC2 or Task Role | Not Configured" or {serviceName}:{ActionName}: implicitDeny
Your ECS task needs a task role or an instance role of the underlying EC2 instance with some permissions for using SSM Session Manager at least. See the IAM permissions required for ECS Exec section and the Enabling logging and auditing in your tasks and services section in the official documentation for the details.
Note that the Condition element of the IAM policy is not currently supported to evaluate by check-ecs-exec.sh.
🟡 SSM PrivateLink "com.amazonaws.(region).ssmmessages" not found
The check-ecs-exec.sh found one or more VPC endpoints configured in the VPC for your task, so you may want to add an additional SSM PrivateLink for your VPC. Make sure your ECS task has proper outbound internet connectivity, and if it doesn't, then you need to configure an additional SSM PrivateLink for your VPC.
🔴 VPC Endpoints | CHECK FAILED
The check-ecs-exec.sh doesn't support checking this item for shared VPC subnets using AWS Resouce Access Manager (AWS RAM). In short, this may not an issue to use ECS Exec if your ECS task VPC doesn't have any VPC endpoint and the task has proper outbound internet connectivity. Make sure to consult your administrator with the official ECS Exec documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html#ecs-exec-considerations) to find if your VPC need to have an additional VPC endpoint.
🟡 Environment Variables : defined
SSM uses the AWS SDK which uses the default chain when determining authentication. This means if AWS_ACCESS_KEY, AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY are defined in the environment variables and the permissions there do not provide the required permissions for SSM to work, then the execute-command will fail. It is recomended not to define these environment variables.

Security

See CONTRIBUTING for more information.

License

Licensed under the MIT-0 License. See the LICENSE file.