-
-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a flag to enable ECS exec for debugging purposes #95
Comments
This issue has been automatically marked as stale because it has been open 30 days |
Given that a Fargate task must be configured with 'awsvpc', and given the code here, it doesn't seem to be possible to attach any policies to the Fargate task role. If that's true, then it is additionally not possible to enable ECS exec for a Fargate task using this module. So with Fargate, this is more of a bug than an enhancement. I also found it somewhat frustrating that there is no mention of the 'needs_iam_role' logic in the module documentation. I spent a few hours trying a variety of workarounds involving use of the various 'iam_*' module parameters with no apparent effect at all. Only after looking at the module source did I realize that all of those parameters are completely ignored when network mode is awsvpc, which is actually the default value, and unlikely to be set otherwise in most cases. Seems crazy to have a bunch of parameters that are ignored by default and not mention it anywhere. |
Perhaps you should browse the ECS documentation https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html#ecs-exec-required-iam-permissions To enable ECS Exec, the permissions should be added to the tasks IAM role |
Yes I finally figured that out last night and managed to get exec-command working with Fargate using this module, thanks for pointing it out. I stand by my comment on the docs though, if there's a condition where a group of parameters is ignored, that should be noted in the documentation. |
Why? |
Because otherwise it is very confusing that making a change to any of those parameters has no effect at all. It makes you think there's a bug in the module, or that there's something wrong with your syntax, etc. It's just very misleading to have a set of parameters that is ignored most of the time, with no explanation of why. A simple statement such as 'This parameter is not used if network mode is awsvpc or if the cluster is attached to a load balancer.', added to the description of each of those parameters, would clarify things. |
But if this is modeled off of the ECS service and its documentation, why the need to double document?
There are numerous examples of this - they are there to prevent users from configuring incorrectly. However, we cannot re-explain the ECS service and all of its facets through the module documentation here |
Any updates on adding this flag to the module? |
This issue has been resolved in version 5.4.0 🎉 |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Is your request related to a new offering from AWS?
Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.
enable_ecs_execute
was released in version3.34.0
Is your request related to a problem? Please describe.
Turning on ECS exec for debugging issues in a container is especially useful during the initial bootstrap of a service; however, the list of considerations for turning this feature on is big, which means there is more room for error; additionally, the error message provided by
aws ecs execute-command
is quite generic, making it difficult to trace problems in the configuration; the AWS team has developed a tool to pinpoint errors in the configuration. Providing a simple method to enable this feature in a container could save time.Describe the solution you'd like.
Add two flags, one that operates at the task definition level in charge of adding the following statements to the task role:
And another that operates at the container level to enable the following features:
The interface exposed to the end user would look something like this:
Design considerations:
In the event of overlapping configurations, the user's configuration takes precedence; here are a few examples:
If
enable_ecs_exec
is set totrue
at the container level andreadonly_root_filesystem
is set totrue
the final configuration would look like this:If
enable_ecs_exec
is set totrue
at the container level andlinux_parameters
is defined, the parameters would be merged:Container configuration:
Describe alternatives you've considered.
Adding all of the configurations by hand or creating a wrapper around this module appears to be a workaround when setting up this feature on ECS, however, more people could benefit if this feature is added to a widely adopted module like this one.
Additional context
It is possible to add all the required configurations by hand with the features exposed by this module, however, it is less convenient and more difficult to troubleshoot errors in the configuration.
The text was updated successfully, but these errors were encountered: