aws-containers / amazon-ecs-exec-checker

🚀 Pre-flight checks for ECS Exec

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

parse error: Invalid escape at line 107, column 25

sogaoh opened this issue · comments

[Console outputs]

with "enableExecuteCommand": false
❯ check-ecs-exec.sh "staging-xxxxxxx-ecs-cluster-artisan" "c1aad09cc7ae435e8c635a11b134078d"
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.31 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off)
  Session Manager Plugin | OK (1.2.54.0)

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxx-ecs-cluster-artisan
Task   : c1aad09cc7ae435e8c635a11b134078d
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::xxxxxxx:user/xxxxxxx
     ecs:ExecuteCommand: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | NO
  Managed Agent Status   | SKIPPED
parse error: Invalid escape at line 107, column 25
with "enableExecuteCommand": true
❯ check-ecs-exec.sh "staging-xxxxxxx-ecs-cluster-artisan" "c9c52abe108343bd8dcb3841f395aeb9"
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.31 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off)
  Session Manager Plugin | OK (1.2.54.0)

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxx-ecs-cluster-artisan
Task   : c9c52abe108343bd8dcb3841f395aeb9
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam:: xxxxxxx:user/xxxxxxx
     ecs:ExecuteCommand: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | OK
  Managed Agent Status   |
     1. RUNNING for "app-back" container
parse error: Invalid escape at line 107, column 25

[Environment info]

  • Mac Mini (Late 2012)
  • macOS Catalina 10.15.7
  • jq --version => jq-1.6
  • AWS region = ap-southeast-1

Thank you @sogaoh for raising this issue! It looks like jq fails to parse the JSON returned from the aws ecs describe-tasks command or the aws ecs describe-task-definition command.
Will take a deeper look into it soon.

@sogaoh I did some tests but still couldn't reproduce this error. Could you try another ECS cluster and/or tasks to see if the error happens too?

@toricls I tried another ECS cluster and task, then the error did not happened...

console output
❯ check-ecs-exec.sh "staging-xxxxxxxx-ecs-cluster-mente" "47752da1f44c415ba42c53fe5d35e836"
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.31 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off)
  Session Manager Plugin | OK (1.2.54.0)

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxxx-ecs-cluster-mente
Task   : 47752da1f44c415ba42c53fe5d35e836
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::123456789012:user/xxxxxxxxxx
     ecs:ExecuteCommand: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | OK
  Managed Agent Status   |
     1. RUNNING for "maintenance" container
  Task Role Permissions  | arn:aws:iam::123456789012:role/staging-xxxxxxxx-ecs-task-execution-role
     ssmmessages:CreateControlChannel: implicitDeny
     ssmmessages:CreateDataChannel: implicitDeny
     ssmmessages:OpenControlChannel: implicitDeny
     ssmmessages:OpenDataChannel: implicitDeny
  VPC Endpoints          |
    Found existing endpoints for vpc-xxxxxxxxxxxxxxxx:
      - com.amazonaws.ap-southeast-1.s3
      - com.amazonaws.ap-southeast-1.ecr.api
      - com.amazonaws.ap-southeast-1.ecr.dkr
      - com.amazonaws.ap-southeast-1.logs
      - com.amazonaws.ap-southeast-1.ssm
    SSM PrivateLink "com.amazonaws.ap-southeast-1.ssmmessages" not found. You must ensure your task has proper outbound internet connectivity.

Thanks for the test @sogaoh!

What I found from the console outputs in your initial comment, was the check-ecs-exec.sh failed due to an error occurred in a jq command execution, and I believe it should have happened after the managed agents' status check around check-ecs-exec.sh#L324-L328. So the parse error in jq command could be occurred by the described task JSON or the task definition JSON, fetched by the check-ecs-exec.sh by executing aws ecs describe-tasks --cluster xxx --tasks yyy and aws ecs describe-task-definition --task-definition zzz CLI commands.

I'd like to have your help to find the root cause, but any chance did you find anything significantly different data between the failed one and the succeeded one in their JSON data?

Maybe irrelevant here but could this be either a jq version mismatch AND/OR a different jq behavior between Linux and Mac? I have seen these being variables in past experiences.

Another parse error: Invalid escape at line 145, column 25 occurred.
The console output is below:

parse error occurred
❯ check-ecs-exec.sh staging-xxxxxxxx-ecs-cluster-back 9d0b0c0eb9754beea1dd898e28fb9044
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.31 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off)
  Session Manager Plugin | OK (1.2.54.0)

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxxx-ecs-cluster-back
Task   : 9d0b0c0eb9754beea1dd898e28fb9044
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::123456789012:user/xxxxxxxx
     ecs:ExecuteCommand: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | NO
  Managed Agent Status   | SKIPPED
parse error: Invalid escape at line 145, column 25

But on another Linux environment, I run check-ecs-exec.sh successfully..

console output
❯ check-ecs-exec.sh staging-xxxxxxxx-ecs-cluster-back 9d0b0c0eb9754beea1dd898e28fb9044
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.32 Python/3.8.8 Linux/4.14.225-168.357.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off)
  Session Manager Plugin | Missing

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxxx-ecs-cluster-back
Task   : 9d0b0c0eb9754beea1dd898e28fb9044
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::123456789012:user/xxxxxxxx
     ecs:ExecuteCommand: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | NO
  Managed Agent Status   | SKIPPED
  Task Role Permissions  | arn:aws:iam::123456789012:role/staging-xxxxxxxx-ecs-task-execution-role
     ssmmessages:CreateControlChannel: allowed
     ssmmessages:CreateDataChannel: allowed
     ssmmessages:OpenControlChannel: allowed
     ssmmessages:OpenDataChannel: allowed
  VPC Endpoints          |
    Found existing endpoints for vpc-xxxxxxxxxxxx:
      - com.amazonaws.ap-southeast-1.s3
      - com.amazonaws.ap-southeast-1.ecr.api
      - com.amazonaws.ap-southeast-1.ecr.dkr
      - com.amazonaws.ap-southeast-1.logs
      - com.amazonaws.ap-southeast-1.ssm
      - com.amazonaws.ap-southeast-1.ssmmessages

OS Information

❯ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

Note: jq version

❯ jq --version
jq-1.5

I'll share the result of aws ecs describe-tasks json to @toricls . Please confirm.
Thanks.

Hi @sogaoh, we've just merged a PR #9, which fixed the script sometimes accidentally uses sh instead of bash, and now I'm suspecting that this problem was the root cause of the errors you observed with your ECS tasks. Could you possibly pull and try the latest check-ecs-exec.sh again to see what happens when you're available?

Thank you for your response.
I'll look at it next Monday.

I've checked by latest check-ecs-exec.sh again, then the result is OK (not occurred parse error) .

Thanks for very much!

checked same as:
#3 (comment)

Result is OK (console output)
❯ check-ecs-exec.sh "staging-xxxxxxxx-ecs-cluster-back" "9d0b0c0eb9754beea1dd898e28fb9044"
-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.1.31 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off)
  Session Manager Plugin | OK (1.2.54.0)

-------------------------------------------------------------
Configurations for ECS task and other resources
-------------------------------------------------------------
Cluster: staging-xxxxxxxx-ecs-cluster-back
Task   : 9d0b0c0eb9754beea1dd898e28fb9044
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::123456789012:user/xxxxxxxx
     ecs:ExecuteCommand: allowed
     ssm:StartSession denied?: allowed
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | NO
  Managed Agent Status   | SKIPPED
  Task Role Permissions  | arn:aws:iam::123456789012:role/staging-xxxxxxxx-ecs-task-execution-role
     ssmmessages:CreateControlChannel: allowed
     ssmmessages:CreateDataChannel: allowed
     ssmmessages:OpenControlChannel: allowed
     ssmmessages:OpenDataChannel: allowed
  VPC Endpoints          |
    Found existing endpoints for vpc-xxxxxxxx:
      - com.amazonaws.ap-southeast-1.s3
      - com.amazonaws.ap-southeast-1.ecr.api
      - com.amazonaws.ap-southeast-1.ecr.dkr
      - com.amazonaws.ap-southeast-1.logs
      - com.amazonaws.ap-southeast-1.ssm
      - com.amazonaws.ap-southeast-1.ssmmessages

I'll close this issue today at 12:00 if nothing else.