Open iJebus opened 1 year ago
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Bump.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Bump.
Since you are using authoritative
All the bindings have to be managed by this code otherwise it will update it whenever there is a change detected.
Hi @imrannayer, thanks for your response. That is actually the case here though.
@iJebus feel free to close the issue/ Thanks
Sorry @imrannayer, my response was unclear. I meant that all bindings were being managed by code and I still believe an issue exists.
I'm also encountering the same problem. It works when we hardcoding the service account emails but when we Implicitly reference a service account block is causes drifts. @imrannayer
It seems like helper function just recrete whole block when you pass a service account which is not created yet.
execute following code
resource "random_id" "svc_rand" {
# byte_length = 2
# }
# resource "google_service_account" "member" {
# project = local.project_id
# account_id = "test-iam-module-${random_id.svc_rand.hex}"
# }
module "helper" {
source = "terraform-google-modules/iam/google//modules/helper"
version = "~> 7.1"
bindings = {
"roles/run.invoker" = [
"serviceAccount:deleteme-1@redated",
"serviceAccount:deleteme-3@redated",
"serviceAccount:deleteme-2@redated",
# "serviceAccount:${google_service_account.member.email}",
]
}
mode = "authoritative"
entities = [local.project_id]
}
output helper_auth {
value = module.helper.bindings_authoritative
}
Now uncomment the lines and execute the code again.
Yep, this would align with what I said originally.
The plan shows the account being created and every role binding in the IAM project module states that it must be replaced.
If I do a targeted apply on the account, the plan then shows only the expected roles being updated/assigned.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Oops, still a thing AFAIK.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Still an issue AFAIK, but I'll stop keeping the issue alive after this because I've moved on from the role where I was using this module.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
We're also affected by this issue, for both the projects and folders IAM modules in authoritative modes. Folder/project is singular and static, same as roles - the only dynamic things are members under specific roles (service accounts). Yet it forces recreation due to apparent diff in folder/project id and role (even though they're not, they're the same between runs).
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
TL;DR
Sometimes I'm seeing very noisy diffs on plans when, for example, a new account is being created and assigned to a role.
I'm not actually sure if this is expected behaviour though.
Expected behavior
The plan should only show the service account being created, and changes in the IAM project module for the roles being assigned.
Observed behavior
The plan shows the account being created and every role binding in the IAM project module states that it must be replaced.
If I do a targeted apply on the account, the plan then shows only the expected roles being updated/assigned.
Terraform Configuration
Terraform Version
Additional information
Example binding replacement diff: