Fix: Ensure that SqsManagedSseEnabled (sqs_managed_sse_enabled) is always passed to CreateQueue SQS API

[nantiferov]

Summary

Affected resource: aws_sqs_queue

Seems that since 01 of September 2022 CreateQueue SQS API changed and if SqsManagedSseEnabled parameter is not passed, SQS created as encrypted by default with aws_sqs_queue resource.

Current logic in provider (internal/attrmap/attrmap.go, ResourceDataToAPIAttributesCreate) omit SqsManagedSseEnabled (sqs_managed_sse_enabled) if it's equal false. Which causes SQS to be created as encrypted and then it's changed to unencrypted on next apply.

This change fixes it, but probably not in a best way.
Closes: #22197

Output from acceptance testing:

NOTE: attrmap package is used in couple of other services, but this change affects only SQS I believe.

$ make testacc PKG=sqs
...
PASS
ok   github.com/hashicorp/terraform-provider-aws/internal/service/sqs 2314.165s

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this pull request by adding a 👍 reaction to the original post to help the community and maintainers prioritize this pull request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

For Submitters

• Please review the contribution guide relating to the type of change you are making to ensure all of the necessary steps have been taken.
• Whether or not the branch has been rebased will not impact prioritization, but doing so is always a welcome surprise.

[github-actions]

Welcome @nantiferov 👋

It looks like this is your first Pull Request submission to the Terraform AWS Provider! If you haven’t already done so please make sure you have checked out our CONTRIBUTOR guide and FAQ to make sure your contribution is adhering to best practice and has all the necessary elements in place for a successful approval.

Also take a look at our FAQ which details how we prioritize Pull Requests for inclusion.

Thanks again, and welcome to the community! 😃

[celik0311]

I am seeing this issue as well. When I set the resource variable to false I need to apply terraform 2x if the value defined is different than the default. As an example, In the case where sqs_managed_sse_enabled is set to false terraform needs to be applied 2x, since when its created it gets set to aws' default of true and then the 2nd apply to set it back to false.

[ewbankkit]

@nantiferov Thanks for the contribution 🎉 👏.

It looks like Amazon announced this change a couple of weeks ago: https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-sqs-announces-server-side-encryption-ssq-managed-sse-sqs-default/.

The best way to fix this is to mark the aws_sqs_queue sqs_managed_sse_enabled attribute as Computed. To ensure backwards compatibility this means that Terraform will only perform drift detection of the attribute's value when present in a configuration.

[BehbudSh]

Hi. I'm sorry but it's not fixed :/. It brakes our Pipeline consitency. It Deploys as a "True" with encryption enabled and tries to disable it when we are deploying again.

[nantiferov]

@ewbankkit thank you for review and merge, but as @BehbudSh mentioned, afaik this won't fix the issue as it's related tosqs_managed_sse_enabled is skipped during creation of SQS if it's false.

[ewbankkit]

@nantiferov Thanks for chasing up on this. As usual, lack of a covering acceptance test case failed to uncover the real problem.
I have made the change to always send a configured sqs_managed_sse_enabled value of false when creating an SQS Queue in #27335.

[github-actions]

This functionality has been released in v4.36.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.