Terraform-provider-aws: Support for account settings flags

[acdha]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

There are several new AWS features for ECS which depend on settings being enabled. I have a workaround for the default running local-exec but it'd be nice if there was a way to do this with the usual Terraform niceties such as change detection:

resource "null_resource" "enable_new_ecs_features" {
  provisioner "local-exec" {
    command = <<EOF
aws ecs put-account-setting-default --name awsvpcTrunking --value enabled
aws ecs put-account-setting-default --name containerInstanceLongArnFormat --value enabled
aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled
aws ecs put-account-setting-default --name taskLongArnFormat --value enabled
EOF
  }
}

New or Affected Resource(s)

• PutAccountSettingDefault

Potential Terraform Configuration

It'd be nice if something like this could work:

resource "aws_ecs_account_setting_default" "vpc_trunking" {
   name = "awsvpcTrunking" 
   value = "enabled"
}

References

• https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_PutAccountSettingDefault.html
• https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html

[slmingol]

The settings page shows 5 things to enable the above example was missing this one - containerInsights.

• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-container-insights.html

[geota]

resource "aws_ecs_account_setting_default" "vpc_trunking" {
   name = "awsvpcTrunking" 
   enabled = true/false
}

imho treating enabled as a bool would be better.

[acdha]

@geota I was wondering about that — it seems like it's mostly a question of how much Terraform wants to try to normalize on top of the underlying API. PutAccountSetting models it as a string field accepting either “enabled” or ”disabled” but I don't know how much they want to hedge against future changes introducing other values. There might be an argument for leaving it as a string so the Terraform data type doesn't need to change but adding a validation rule which can be extended in the future.

[VR6Pete]

Its worth noting the following points from the AWS documentation;

• Through the end of December 2019, new ARNs/IDs will be available for opt-in via APIs and the ECS Console. All accounts can opt-in and out as needed for testing. Starting on January 1, 2020, the option to switch formats will no longer be available, and newly-created ECS resources will all receive the new ARNs and ID formats.

• Until March 31st, 2019 all newly-created AWS accounts will continue to default to the current formats. Starting April 1st, 2019, all newly-created accounts will be automatically opted-in, but you will retain the option to opt-out until December 31st 2019.

Obviously appreciate that there will be people with existing workloads that fall outside of the above points.

In short - from 1st January 2020 whether you have opted out or not yet opted out will switched to the new extended ARN format, not sure if there is much of a use case here considering its going to be enabled by default, and given a good work-around exists using local-exec resource for what effectively is a one time action.

[acdha]

@VR6Pete Note that I was specifically requesting a general mechanism: while certain flags become moot over time, I doubt that AWS will discontinue future use of opt-in flags and the syntax I suggested would be future-proof until they change the API types.

[gurpreetatwal]

Worth noting that there doesn't seem to be a plan to enable "Container Insights" or "AWSVPC trunking" by default, so it would still be worth it to have this resource for those settings.

[shmick]

Its worth noting the following points from the AWS documentation;

• Through the end of December 2019, new ARNs/IDs will be available for opt-in via APIs and the ECS Console. All accounts can opt-in and out as needed for testing. Starting on January 1, 2020, the option to switch formats will no longer be available, and newly-created ECS resources will all receive the new ARNs and ID formats.
• Until March 31st, 2019 all newly-created AWS accounts will continue to default to the current formats. Starting April 1st, 2019, all newly-created accounts will be automatically opted-in, but you will retain the option to opt-out until December 31st 2019.

Obviously appreciate that there will be people with existing workloads that fall outside of the above points.

In short - from 1st January 2020 whether you have opted out or not yet opted out will switched to the new extended ARN format, not sure if there is much of a use case here considering its going to be enabled by default, and given a good work-around exists using local-exec resource for what effectively is a one time action.

While creating an ECS service in newly created AWS account, I received the following error:

Error: InvalidParameterException: The new ARN and resource ID format must be enabled to add tags to the service. Opt in to the new format and try again

On Jan 14 2020 AWS back tracked on this decision. AWS post is here.

Is there any straight forward Terraform way to enable this options?

[Gowiem]

Yeah, looking for the same functionality and agree I think it would be future proof as there will be similar things that AWS / ECS will enable through similar settings.

Important to note, AWS still hasn't done anything about this since their message in January (from the above linked blog post):

Update – January 14, 2020 – This blog was updated to remove a note about the change to ARN and ID formats on ECS resources impacting all new resources starting on January 1, 2020. That is no longer accurate and we will post new information once available.

[Tensho]

I tried to implement aws_ecs_account_setting_default resource, but encountered some API inconsistency. PutAccountSettingDefault API action sets default values at account level as expected. However, ListAccountSettings API counterpart action works at current user/role level fetching effective values. The only possible way to get account default settings with ListAccountSettings API – set principal to root user. I don't think you want to run Terraform on behalf of root user. The same situation is with DeleteAccountSetting API action.

It would be nice AWS will kindly provide ListAccountDefaultSettings and DeleteAccountSettingDefault API actions.

[sergei-ivanov]

@Tensho I also had a go at it and gave up after facing the same problem. _Default_ account settings are essentially settings for the root user. A user with admin privileges can set them, but cannot read back or delete. That only gives us 2 out of 4 CRUD operations required for implementing a resource (and no way of implementing a reliable data source either). It should still be possible to implement aws_ecs_account_setting resource and data source for the current user/role, but that has a potential to result in unstable terraform plans, in the case when terraform configuration is applied by different users or users assuming different roles.

[acdha]

Is there an open request with Amazon to improve this API?

[robh007]

Hi,
I've read through the above comments and I sort of disagree. I think the documentation on the API is possibly worded wrongly/badly. But it is possible & you can create and manage resources at an account level for the root user without being logged in as the root user. However it seems that the delete action doesn't work for the root principal. This I think is to be expected although I'm going to seek clarity from AWS. You can do two things enable or disable, if you try and delete the root principal setting you get an empty response.

I've created a resource as outlined above, I think there's a requirement for another resource to manage the user/role level interaction. This resource turns ECS account default settings on at the root level and this is done per region. The tests I've created & ran, test for each possible setting being enabled and the principal arn being returned as root. I did try a couple of examples with the AWS CLI and I think there's a bug in there or a misinterpretation.

resource "aws_ecs_account_setting_default" "test" {
  name = "taskLongArnFormat"
  value = "enabled"
}

[sergei-ivanov]

From my experiments with AWS CLI under non-root admin user:
It is possible to set and update the default settings. It is possible to read them back only if there is no setting for the current role (effective_setting flag must be on and then root setting is returned). If there is a setting defined for the current role/user, then there is no way to read the default setting: it is completely obscured. An attempt to read it by passing root principal ends up with access denied. It is not possible to delete the root setting either (access denied).

[robh007]

Hi @sergei-ivanov, I've dug a little deeper into this & I get what you're saying. However I feel there's still two use cases and both need to be addressed with different resources and perhaps more/better documentation around those use cases. Maybe the code can handle the fact that the principal ARN as already set a value other than root on PutAccountSettingDefault if this gets returned in the response.

The PutAccountSettingDefault was designed for a one of use case, so that you didn't need to log in as the root account to toggle it. See issue on ecs roadmap. This I still think is the majority of peoples use cases.