-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Changes to inline_policy
blocks on aws_iam_role
always recreates policy
#22336
Comments
inline_policy
blocks on aws_iam_role
always show as recreationsinline_policy
blocks on aws_iam_role
always recreates policy
Adding some extra information as I think this is also related but not 100% sure. When using a blank inline policy (which enforces that any added inline policy is removed). See example: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_role#example-of-removing-inline-policies As of version 3.70 the inline block will always show a change (even if there is no inline policy to remove): 3.69.0 works as expect. |
I also have this issue, but I don't think it's the same cause, so it should probably be split out into a different ticket. I believe the inline policy update issue is not a regression. |
This makes it difficult to see what the actual changes to the policy are. |
I think part of the problem here is that the schema of Alternatively, maybe it would be possible to create a custom diff for |
This is actually a bit of a theme in a lot of issues with this provider: |
@tmccombs Hit the same issue. I'll take a look at updating the custom diff for the policies to see if that could be updated to resolve this as that would break backwards compatibility. |
I guess another alternative would be to have some sort of flag for not using @justinretzolk Would it be possible to have one of the maintainers give input in here before I start development? More than willing to help contribute this, just need to know which direction I should go before I start development. |
One advantage of inline_policy over aws_iam_role_policy, is that it is better for detecting drift, since it will show a diff if there is a policy that isn't managed as part of the role. There is a similar issue with security group rules. |
@tmccombs Ahhh good point. Let me make an upstream issue on terraform then because as you said, this seems like a common issue with |
So from this thread from discuss Hashicorp about |
Are there any plans to migrate this provider to the terraform-plugin-framework? |
I'm going to attempt to upgrade |
I'm going to try to break this updates into parts as much as possible as it will be a pretty big changeset. This first PR is just add arn valid functionality to internal terraform validators for the plugin framework |
@justinretzolk Not sure the right channel to ask this but wanted to check before working more on my PR to upgrade the IAM resource to the plugin framework from sdk v2. I was planning on taking the |
@teddylear were you able to get any direction on this? cc @justinretzolk |
@atheiman I haven't so far. I was waiting on a response, but for now I'll continue to work on this with using the |
Was able to make above open PR that should resolve issue. resource "aws_iam_role" "main" {
assume_role_policy = data.aws_iam_policy_document.trust.json
name = "terraform-issue-reproduction"
inline_policies = {
"InlinePolicy" = data.aws_iam_policy_document.inline.json
}
}
# Inline policy document that we'll be changing
data "aws_iam_policy_document" "inline" {
statement {
sid = "S3"
actions = ["s3:ListBucket"]
resources = [
"arn:aws:s3:::some-bucket-a",
# After the first apply, uncomment this next line
# "arn:aws:s3:::some-bucket-b",
]
}
}
# Minimal, arbitrary trust statement to make the role valid
data "aws_iam_policy_document" "trust" {
statement {
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["apigateway.amazonaws.com"]
}
}
} And the plan to add second bucket in inline policy produces this plan which is close to original one in ticket: # aws_iam_role.main will be updated in-place
~ resource "aws_iam_role" "main" {
id = "terraform-issue-reproduction"
~ inline_policies = {
~ "InlinePolicy" = jsonencode(
~ {
~ Statement = [
~ {
~ Resource = "arn:aws:s3:::some-bucket-a" -> [
+ "arn:aws:s3:::some-bucket-b",
+ "arn:aws:s3:::some-bucket-a",
]
# (3 unchanged attributes hidden)
},
]
# (1 unchanged attribute hidden)
}
)
}
name = "terraform-issue-reproduction"
# (8 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy. Adding a third bucket produces this plan which is even more user friendly: # aws_iam_role.main will be updated in-place
~ resource "aws_iam_role" "main" {
id = "terraform-issue-reproduction"
~ inline_policies = {
~ "InlinePolicy" = jsonencode(
~ {
~ Statement = [
~ {
~ Resource = [
+ "arn:aws:s3:::some-bucket-c",
"arn:aws:s3:::some-bucket-b",
# (1 unchanged element hidden)
]
# (3 unchanged attributes hidden)
},
]
# (1 unchanged attribute hidden)
}
)
}
name = "terraform-issue-reproduction"
# (8 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy. If there is anything I should change to update about this please let me know. |
Hello everyone - thanks for your interest and participation in this issue! I wanted to provide an update after some internal investigation from maintainers. First, we revisited #35634, which has migrated the Given this existing pull request included changes beyond a single argument addition, we next investigated adding a new
Concerns around complexity led us to explore another pattern, now the subject of an open proposal, to implement "exclusive relationship management" resources. The inability to "exlusively manage" inline policy assignments using the standalone resource has often been cited as a barrier to using this currently available aoption. While this does not resolve the issue with the The configuration and output below displays how this would function in the case where a standalone inline policy is modified: Show/Hide Configurationdata "aws_iam_policy_document" "trust" {
statement {
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["ec2.amazonaws.com"]
}
}
}
data "aws_iam_policy_document" "inline" {
statement {
actions = ["s3:ListBucket"]
resources = [
"arn:aws:s3:::some-bucket-a",
"arn:aws:s3:::some-bucket-b",
]
}
}
resource "aws_iam_role" "test" {
name = "jb-test-role-policies-lock"
assume_role_policy = data.aws_iam_policy_document.trust.json
}
resource "aws_iam_role_policy" "test" {
name = "test-inline"
role = aws_iam_role.test.name
policy = data.aws_iam_policy_document.inline.json
}
resource "aws_iam_role_policies_exclusive" "test" {
role_name = aws_iam_role.test.name
policy_names = [
aws_iam_role_policy.test.name,
]
} % make plan
TF_CLI_CONFIG_FILE=dev.tfrc terraform plan
╷
│ Warning: Provider development overrides are in effect
│
│ The following provider development overrides are set in the CLI configuration:
│ - hashicorp/aws in /Users/jaredbaker/go/bin
│
│ The behavior may therefore not match any released version of the provider and applying changes may cause the state to become incompatible with published releases.
╵
data.aws_iam_policy_document.inline: Reading...
data.aws_iam_policy_document.trust: Reading...
data.aws_iam_policy_document.inline: Read complete after 0s [id=748695472]
data.aws_iam_policy_document.trust: Read complete after 0s [id=2851119427]
aws_iam_role.test: Refreshing state... [id=jb-test-role-policies-lock]
aws_iam_role_policy.test: Refreshing state... [id=jb-test-role-policies-lock:test-inline]
aws_iam_role_policies_exclusive.test: Refreshing state...
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# aws_iam_role_policy.test will be updated in-place
~ resource "aws_iam_role_policy" "test" {
id = "jb-test-role-policies-lock:test-inline"
name = "test-inline"
~ policy = jsonencode(
~ {
~ Statement = [
~ {
~ Resource = "arn:aws:s3:::some-bucket-a" -> [
+ "arn:aws:s3:::some-bucket-b",
+ "arn:aws:s3:::some-bucket-a",
]
# (2 unchanged attributes hidden)
},
]
# (1 unchanged attribute hidden)
}
)
# (2 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy. SummaryAt this time our proposal is to proceed with the addition of a new |
I like that approach. It would also be useful in other places, like security group rules. |
I am not interested in using Personally id rather a new
If Edit: oh i see, Edit 2: I should say i really do appreciate the thoughtful reply and review of the issue. Thanks. |
Agreed! Security group rules to security groups is one of the relationships covered in the |
@atheiman - Thanks for your feedback! We understand the hesitation to introduce another resource into configuration. As maintainers we're attempting to balance the potential confusion of introducing "yet another way" to manage inline policies (should I use The full proposal has more detailed research and justification, so I won't add more to an already long thread here. I mostly want to describe that we weighed both options equally (including a working POC and RFC on the |
Hello everyone - I wanted to share an update. The proposal for “exclusive relationship management” resources has been approved, and we’re proceeding with implementing a standalone resource to allow Terraform to exclusively manage inline policy assignments (#39203). A consequence of this decision is that we are not intending to add a new argument to the Lastly, since the |
While removing the deprecated arguments from my config I noticed the warning doesn't mention which argument is deprecated:
Shouldn't this warning mention that it's the |
Thanks for the suggestion @BroMattMiller. #39430 has updated the deprecation message and added some detail to the registry documentation which was missed in the previous PR. |
For those looking to migrate from the deprecated |
Sometimes I don't want to create standalone policy because it is exclusive only for given role. With this new resource I'm forced to create standalone policy and then I can link this managed role to mimic inline role but I still have to maintain this managed "blueprint". Is my understanding correct? Also, is it only deprecation or active plan for removal of Also, 2-weeks is a little short notice to gather real feedback. Especially when announcement is done via deprecation warning (this is how I come to this issue). |
Hi @kkurczewski - thanks for your feedback! I'll respond to each of these separately.
The standalone Please let me know if I misunderstood what you were looking for clarification on with this question.
Here is a relevant section of the underlying proposal.
TLDR; we have no plans to remove this argument in the next major version. The deprecation is primarily to allow maintainers and community members to have explicit direction on the preferred pattern for defining inline policies going forward.
The two week window is specific to closing this issue, and since discussion on this topic has spanned several years now we felt it best to set a date for resolution. The only viable option to resolving the original issue with re-creation of policies defined via the Hope this helps to clarify our thinking here, and thanks again for your feedback. |
Okay, that's a big relief for me 👍
I see, fair enough. Regarding my concerns about usage of new resource, thanks for additional clarification. I need to sort it in my head and perhaps try it in practice with actual Terraform code, once then I will back to you. |
@jar-b tl;dr; yeah, you are right. I was just confused.
Okay, I checked with Terraform and now I see you were right and I just confused As Fun fact, when writing this post I also did similar mistake and confused Also, for some strange reason I had mental model where On occasion I will try to play with this new resource and report additional feedback, if any. |
Completely understand - the naming of these resources, while in line with the AWS API's, does make distinguishing inline versus customer managed policies difficult. I often find myself in the registry docs just to be sure :). Appreciate your openness to trying out the new resource. Any feedback would be great! |
The feedback window has elapsed and we have not received justification to keep the original request open. For related feature requests please open a new issue, optionally linking to this one. |
Warning This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them. Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed. |
Warning This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them. Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed. |
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
resource.aws_iam_role
data.aws_iam_policy_document
in the reproductionTerraform Configuration Files
Debug Output
Redacted debug-level log: https://gist.github.com/danopia/0941f0d5f487432770c670603b221ea1
Expected Behavior
Because the
inline_policy
blocks have the samename
value, Terraform should view this change as an update to the existinginline_policy
:I'd expect the diff to look like this:
Actual Behavior
Terraform prints a diff showing an
inline_policy
removal and then also aninline_policy
creation:Also, from the attached debug log, we can see that Terraform is actually doing a delete-then-create sequence:
Steps to Reproduce
terraform apply
some-bucket-b
terraform apply
References
I've found this issue mentioned within other
inline_policy
issues:The text was updated successfully, but these errors were encountered: