Auth fails with "retry function failed after 1 attempt: failed to generate Google Cloud access token"

Hi there @PaulRudin 👋!

Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps.

Hi @PaulRudin - please review the troubleshooting steps. There are many common misconfigurations that cause that error.

Yup, I read that. I guess the fact that there are many potential misconfigurations that makes it tricky to spot the problem.

Did you provide sa_mappings in that Terraform configuration?

Yeah, that block is defined by:

    sa_mapping: {
	"github-fplscore-sa" : {
	  sa_name: "${google_service_account.github_fplscore_sa.name}",
	  attribute: "attribute.repository/PaulRudin/fplscore",
	},
	"github-fplserve-sa": {
	  sa_name: "${google_service_account.github_fplserve_sa.name}",
	  attribute: "attribute.repository/PaulRudin/fplserve",
	}
      }

I tried enabling audit logging as suggested in the troubleshooting guide, but I couldn't see any log entries that seem relevant after rerunning the workflow. But I'm not sure what I should be looking for.

I'm experiencing the same problem. Service account impersonation is not working, been trying for two days now.
I've tried all the steps in the troubleshooting docs, and in closed issues; I simply cannot limit a service account to any attributes, or even the subject field.
I'm able to get around this issue by using conditions on the provider; and allowing service accounts to access "all identities in the pool". This effectively limits me to one service account per provider, which I guess is fine for my use-case.

I'm pretty confident that something is wrong with service account impersonations. I can't find anything useful in the logs tho. To reproduce, try to limit a service account to repository_owner with the latest version of the auth workflow. I just set up the pool using my browser as a test; everything seems to be in order, and the principalSet IAM rules generated by console actions seem correct, but the action still fails with failed to generate Google Cloud access token.

So, based on that I just used a single service account and used "*" as the attribute in the sa_mapping, and now the authentication seems to succeed.

Hi @PaulRudin @djfinnoy

Did you provide any attribute mappings in the configuration (Terraform)? See step 3 of the troubleshooting guide, but you must have an attribute mapping for any attribute conditions. You cannot create an attribute condition unless you map values from the incoming GitHub OIDC token. In that Terraform module, it would be something like:

module "gh_oidc" {
  source      = "terraform-google-modules/github-actions-runners/google//modules/gh-oidc"
  # ...

  attribute_mapping = {
    "google.subject": "assertion.sub"
    "attribute.repository" : "assertion.repository"
  }

  sa_mapping = {
    "foo-service-account" = {
      sa_name   = "projects/my-project/serviceAccounts/[email protected]"
      attribute = "attribute.repository/user/repo"
    }
  }
}

Also double check capitalization on the repository owner and repository names.

Facing the same error on my side. After upgrading to v1 it broke my pipeline.

Hi @lucasmellos - there were only documentation changes between v0 and v1, so I'm not sure how that would affect your pipeline.

Yes, I did the attribute mapping bit. When you manage workload identity pools through the console in your browser, you won't even be able to configure impersonation filters without the attribute mappings.

Is it possible that something is broken on the GCP Workload Identity pool side of the equation?
I had some trouble with provider conditions; attribute.repository == "my-org/my-repo" didn't work, while assertion.repository == "my-org/my-repo" worked fine. Based on the docs, I was under the impression that one could use attribute.<x> for the provider conditions, so I'm wondering if maybe something is wrong with attribute mappings in GCP.

Edit:
It's also possible that I'm just doing the attribute mappings wrong when setting them up via the console. Will try it through Terraform and see if that yields different results.

On my side, it was the lack of SA attachment. Notting related to this action.

Hi @djfinnoy - it's also possible that you're not waiting ~5min in between changes. WIF pools take a long time to provision and are eventually consistent, especially configuration changes. Attribute conditions should be attribute.something.

Hi @PaulRudin @djfinnoy

Did you provide any attribute mappings in the configuration (Terraform)? See step 3 of the troubleshooting guide, but you must have an attribute mapping for any attribute conditions. You cannot create an attribute condition unless you map values from the incoming GitHub OIDC token. In that Terraform module, it would be something like:

module "gh_oidc" {
  source      = "terraform-google-modules/github-actions-runners/google//modules/gh-oidc"
  # ...

  attribute_mapping = {
    "google.subject": "assertion.sub"
    "attribute.repository" : "assertion.repository"
  }

  sa_mapping = {
    "foo-service-account" = {
      sa_name   = "projects/my-project/serviceAccounts/[email protected]"
      attribute = "attribute.repository/user/repo"
    }
  }
}

Also double check capitalization on the repository owner and repository names.

I didn't specify the attribute mapping explicitly, but that terraform module has a default that includes the mapping you suggest: https://github.com/terraform-google-modules/terraform-google-github-actions-runners/blob/760e9710da0a2378d2acbb58fb4c06c007b4ec79/modules/gh-oidc/variables.tf#L68

@PaulRudin understood. Unfortunately without more information, it's difficult to debug this. Have you enabled the Security Token Service Activity logs for Admin, Data Read, and Data Write and looked at the logs?

After creating a WI pool and provider with Terraform, I have realized that my issues were caused by misconfigured attribute mappings.

For some reason, when defining these mappings in the console, I deceived myself into thinking one should enquote CEL strings. This was a mistake, and lead to broken attribute mappings that cannot be utilized by neither the provider's attribute conditions, nor the service account impersonations.

To demonstrate my error, all attribute mappings except repository_owner are correct and working in the pic below:

Edit:
Some debug advice: If you can't get service account impersonations to work, try using the same attributes within the provider conditions. If this doesn't work, you are probably dealing with misconfigured attribute mappings.
I found the following action useful for debugging: https://github.com/github/actions-oidc-debugger

Hi @PaulRudin - can you share some screenshots of your Pool and Provider configuration please?

As I mentioned I've now switch to a single service account and using '*' for the attribute and things work on that basis. I'll try to make a minimal reproducible example without messing with my existing setup.

Hey @PaulRudin - any luck on building a reproduction case?