Unexpected diffs on plans using the project module

[iJebus]

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

module "projects_iam_bindings" {
  source  = "terraform-google-modules/iam/google//modules/projects_iam"
  version = "~> 6.4"

  projects = [var.project_id]
  mode     = "authoritative"

  bindings = {
    "roles/run.invoker" = [
      "serviceAccount:a",
      "serviceAccount:b",
      "serviceAccount:c",
      "serviceAccount:d"
    ]
  }
}

resource "google_service_account" "y" {
  project      = var.project_id
  account_id   = "y"
  display_name = "y"
  description  = "y"
}

Terraform Version

Terraform v1.3.6
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v4.46.0
+ provider registry.terraform.io/hashicorp/google-beta v4.46.0
+ provider registry.terraform.io/hashicorp/null v3.2.1
+ provider registry.terraform.io/hashicorp/random v3.4.3

Additional information

Example binding replacement diff:

  # module.iam.module.projects_iam_bindings.google_project_iam_binding.project_iam_authoritative["default--roles/run.invoker"] must be replaced
+/- resource "google_project_iam_binding" "project_iam_authoritative" {
      ~ etag    = "BwX2dPWNm1k=" -> (known after apply)
      ~ id      = "x/roles/run.invoker" -> (known after apply)
      ~ members = [
          - "serviceAccount:a",
          - "serviceAccount:b",
          - "serviceAccount:c",
          - "serviceAccount:d",
        ] -> (known after apply)
      ~ project = "x" -> (known after apply) # forces replacement
      ~ role    = "roles/run.invoker" -> (known after apply) # forces replacement

      + condition { # forces replacement
          + description = (known after apply)
          + expression  = (known after apply)
          + title       = (known after apply)
        }
    }

[github-actions]

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

[iJebus]

Bump.

[github-actions]

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

[iJebus]

Bump.

[imrannayer]

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.

[iJebus]

Hi @imrannayer, thanks for your response. That is actually the case here though.

[imrannayer]

@iJebus feel free to close the issue/
Thanks

[iJebus]

Sorry @imrannayer, my response was unclear. I meant that all bindings were being managed by code and I still believe an issue exists.

[deepak-rxt]

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

[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.

[iJebus]

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.

[github-actions]

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

[iJebus]

Oops, still a thing AFAIK.

[github-actions]

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

[iJebus]

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.

[github-actions]

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

[github-actions]

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

[afafara]

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).