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

Breaking change in 4.1.1 - Attribute iam_emails returns full service account id / name instead of account_id #59

Open
philippeboyd opened this issue Feb 18, 2022 · 11 comments
Labels
bug Something isn't working triaged Scoped and ready for work

Comments

@philippeboyd
Copy link

philippeboyd commented Feb 18, 2022

TL;DR

Attribute iam_emails returns full service account id / name instead of account_id (same with return attribute emails)

Expected behavior

> module.service_accounts.iam_emails
{
  "first" = "serviceAccount:prefix-first@<project_id>.iam.gserviceaccount.com"
  "second" = "serviceAccount:prefix-second@<project_id>.iam.gserviceaccount.com"
}

Observed behavior

> module.service_accounts.iam_emails
{
  "projects/<project_id>/serviceAccounts/prefix-first@<project_id>.iam.gserviceaccount.com" = "serviceAccount:prefix-first@<project_id>.iam.gserviceaccount.com"
  "projects/<project_id>/serviceAccounts/prefix-second@<project_id>.iam.gserviceaccount.com" = "serviceAccount:prefix-second@<project_id>.iam.gserviceaccount.com"
}

Terraform Configuration

module "service_accounts" {
  source        = "terraform-google-modules/service-accounts/google"
  version       = "4.1.1"
  project_id    = "<project_id>"
  prefix        = "prefix"
  names         = ["first", "second"]
}

Terraform Version

Terraform v1.1.6
on darwin_amd64
+ provider registry.terraform.io/hashicorp/google v4.11.0
+ provider registry.terraform.io/hashicorp/google-beta v4.11.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/time v0.7.2

Additional information

Related to PR #57

Version 4.1.0 was convenient in the following use case:

module "service_accounts" {
  source        = "terraform-google-modules/service-accounts/google"
  version       = "4.1.0"
  project_id    = "<project_id>"
  prefix        = "prefix"
  names         = ["first", "second"]
}

module "buckets" {
  source  = "terraform-google-modules/cloud-storage/google"
  version = "~> 3.1"

  project_id = <project_id>
  location   = "northamerica-northeast1"
  prefix     = ""
  names = [
    "bucket-first",
    "bucket-second",
  ]

  set_viewer_roles = true
  bucket_viewers = {
    "bucket-first" = module.service_accounts.iam_emails["first"], # <- no longer works since key `first` doesn't exist
    "bucket-second" = module.service_accounts.iam_emails["second"], # <- no longer works since key `second` doesn't exist
  }
}
@philippeboyd philippeboyd added the bug Something isn't working label Feb 18, 2022
@philippeboyd
Copy link
Author

Looping in PR owner @wkrysmann

@philippeboyd
Copy link
Author

Attribute service_accounts_map returns proper module specified names as keys so a workaround is to use

  bucket_viewers = {
    "bucket-first" = "serviceAccount:${module.service_accounts.service_accounts_map["first"]["email"]}",
    "bucket-second" = "serviceAccount:${module.service_accounts.service_accounts_map["second"]["email"]}",
  }

Still a breaking change though...

@morgante
Copy link
Contributor

This should be considered a bug, since we didn't intend to change the interface of service_accounts. If you can get a PR up to fix it, we can change it back quickly.

@philippeboyd
Copy link
Author

Changing it back would be to revert PR #57 (commit cb0f7f0) but then the problem that @wkrysmann mentioned in his PR would be back. Hence I would like to get his inputs on this issue first.

@wkrysmann
Copy link
Contributor

Hi @philippeboyd,
thanks for flagging this out, this is definitely a bug which I introduced unintentionally.
I'm wondering if we could use service_accounts_map, similarly to how you use it in workaround solution to fix iam_emails output.

@github-actions
Copy link

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 github-actions bot added the Stale label Apr 24, 2022
@philippeboyd
Copy link
Author

not stale

@github-actions github-actions bot removed the Stale label Apr 29, 2022
@mehdicopter
Copy link

Attribute service_accounts_map returns proper module specified names as keys so a workaround is to use

  bucket_viewers = {
    "bucket-first" = "serviceAccount:${module.service_accounts.service_accounts_map["first"]["email"]}",
    "bucket-second" = "serviceAccount:${module.service_accounts.service_accounts_map["second"]["email"]}",
  }

Still a breaking change though...

I did use this instead:

bucket_viewers = {
    "bucket-first" = "serviceAccount:${module.service_accounts.service_accounts_map.first.email}",
    "bucket-second" = "serviceAccount:${module.service_accounts.service_accounts_map.second.email}",
  }

@bharathkkb bharathkkb added the triaged Scoped and ready for work label May 6, 2022
@ccogan-lh
Copy link

Any update on this?

@corey-hammerton
Copy link

Is there any update to this issue? We do use the service_accounts_map output, but it renders the output variables emails and iam_emails effectively useless

@adrian-gierakowski
Copy link
Contributor

adrian-gierakowski commented May 12, 2023

just hit this problem: it was an unannounced breaking changed, would be great to get it fixed
for now this is my workaround:

locals {
  service_accounts_iam_emails_by_name = {
    for env, account in module.service-accounts.service_accounts_map:
      env => "serviceAccount:${account.email}"
  }
}

this issues affects the emails output as well

IMHO best approach would be a fix reverting to original behaviour released as a breaking change with major version update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triaged Scoped and ready for work
Projects
None yet
Development

No branches or pull requests

8 participants