Skip to content
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

Reason for deprecating aws_iam_role.managed_policy_arns #39771

Open
sylr opened this issue Oct 17, 2024 · 10 comments
Open

Reason for deprecating aws_iam_role.managed_policy_arns #39771

sylr opened this issue Oct 17, 2024 · 10 comments
Labels
question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com.

Comments

@sylr
Copy link
Contributor

sylr commented Oct 17, 2024

Description

Hi,

As a pretty extensive user of AWS IAM roles, deprecating aws_iam_role.managed_policy_arns in favor of a new aws_iam_role_policy_attachments_exclusive resource is going to have a non negligible and unwanted impact on my Terraform Cloud bill.

I'd like an explanation for this change.

Regards.

References

No response

Would you like to implement a fix?

None

Copy link

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this 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.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Oct 17, 2024
@alexbacchin
Copy link
Contributor

#22336

@IgorMilavec
Copy link
Contributor

#22336

I don't see how this relates. aws_iam_role.managed_policy_arns vs aws_iam_role_policy_attachments_exclusive should just be an implementation detail, I see no need to force all of the consumers to invest heavily in changing their IaC.

@mimozell
Copy link

Not sure what you mean by the Terraform Cloud bill, but this change is very annoying and the reasoning behind it doesn't seem clear to me either 😞

@mimozell
Copy link

mimozell commented Oct 18, 2024

Seems like it is related to: #39718, #39376, #39204

And the easiest to read is here: https://github.com/hashicorp/terraform-provider-aws/blob/main/docs/design-decisions/exclusive-relationship-management-resources.md

@sylr
Copy link
Contributor Author

sylr commented Oct 18, 2024

Not sure what you mean by the Terraform Cloud bill

Terraform Cloud bills you per number of resources managed.

Moving relations from attributes to dedicated resources increases your bill.

@jar-b jar-b added question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com. and removed needs-triage Waiting for first response or review from a maintainer. labels Oct 21, 2024
@jar-b
Copy link
Member

jar-b commented Oct 21, 2024

Hey @sylr - thanks for your question. The short answer is to reduce the scope of responsibility for the aws_iam_role resource.

Arguments like managed_policy_arns or inline_policy force a single resource to manage the lifecycle of other related resources. This can lead to partially successful apply operations, which introduces with another set of failure modes to handle. In general this is a pattern we're attempting to move away from, as documented in the proposal for exclusive relationship management resources linked above.

We understand that migrating arguments on such a foundational resource will require a non-trivial amount of effort, which is why we don't have imminent plans to remove the argument. A relevant section from the proposal:

Due to the popularity of the resources in this section, argument deprecations are likely to be "soft" deprecations where removal will not happen for several major releases, or until tooling is available to limit the amount of manual changes required to migrate to the preferred pattern. Despite this long removal window, a soft deprecation is still helpful for maintainers to reference when making best practice recommendations to the community.

We have no plans to remove this argument in the next major version, so you can continue using the existing argument without any changes to your TFC resource count. Hopefully this helps to describe our thinking with this change!

@lawliet89
Copy link
Contributor

lawliet89 commented Jan 8, 2025

Thank you @jar-b for your comment. I understand the reasoning/principles behind this.

Since this attribute is "deprecated", it will be slated for removal some time in the future even if it's not the next major release so the concern regarding a multiplicative effect on our RUM will still exist.

As a result of RUM, we are already trying to migrate away from using resources like aws_iam_role_policy_attachment where possible and this is yet another roadblock in our attempt to reduce our RUM.

I am aware that this is not directly related to the provider itself, but it's a big concern on our end as customers of HCP Terraform.

@AnitaErnszt
Copy link
Contributor

AnitaErnszt commented Jan 13, 2025

Moving my issue here, as it was marked duplicated

This deprecation is also causing an issue for us, without suitable alternative:

The problem

Removing the managed_policy_arns from aws_iam_role will result in having to explicitly configure dependencies in terraform, rather than relying on implicit dependencies.

Whilst aws_iam_role_policy_attachments_exclusive can help to keep resources in declarative state (eg someone manually added a new permission manually, it'll be cleaned up), it can't help terraform to apply changes in the correct order.

Example

I have a lambda, and I want to update the code and permissions to read from Dynamo.

Right now: I can just add the IAM policy in the managed_policy_arns section of the IAM role, and be sure that the IAM role will be updated first, then the Lambda code that references the IAM role.

With the proposed deprecation: I'll have to create a new aws_iam_role_policy_attachment, then add a depends_on to my Lambda, referencing the new aws_iam_role_policy_attachment. Without the depends_on block, there might be a case where my Lambda is updated first, and the permission is updated only after, leading to temporary downtime due to insufficient permissions.

@ei-grad
Copy link
Contributor

ei-grad commented Jan 24, 2025

Is there a guide on how to perform such a migration? Does it have to be "terraform state rm" followed by "import"? It feels quite cumbersome and insecure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com.
Projects
None yet
Development

No branches or pull requests

8 participants