Default variables are partition sensitive
Closed this issue · 4 comments
Description
I am trying to deploy a Terraform module to GovCloud that contains an ECS service using this resource, but the default setup fails because the ARNs from the default variables are malformed (with the wrong partition).
- ✋ I have searched the open/closed issues and my issue is not listed.
Versions
-
Module version [Required]:
-
Terraform version: 1.4.0
-
Provider version(s): 4.57.0
Reproduction Code [Required]
Use any example, but target a GovCloud or AWS CN account for deployment
Steps to reproduce the behavior:
- Deploy to a GovCloud or AWS CN account without setting an explicit value for sensitive variables, e.g.
task_exec_ssm_param_arns
Expected behavior
Deployment should not be sensitive to current partition
Actual behavior
Deployment is sensitive to current partition
these are just defaults - its recommended to use the actual ARNs of the SSM parameters and/or SecretsManager secrets in order to provide scoped access to only the specified values
Forgive me, but that seems harsh and against the principles of AWS in terms of safe out-of-the-box deployments. For instance if you look at AWS CDK, they would never have a paradigm like this, because partition-awareness if baked into every layer of the stack. I strongly encourage you to reopen this issue, and restructure the variables such that instead of a default variable, you have an optional variable for add_default_ssm_policy (etc), with a default value of true. Then, the data source can be used to add this policy.
I strongly encourage you to reopen this issue, and restructure the variables such that instead of a default variable, you have an optional variable for add_default_ssm_policy (etc), with a default value of true.
I strongly encourage you to specify the ARNs of the SSM parameters and/or SecretsManager secrets that you wish to provide access to your Task(s). This is the correct, and most secure manner for this value. We have provided default values to help users get up and running quickly without too many surprises, but scoping access will fall on the users side of the shared responsibility model
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.