-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Handle 3rd-party identities in IAM correctly #7852
Handle 3rd-party identities in IAM correctly #7852
Comments
This appears to be a legit case |
I have been working on a number of PR’s over the last couple of weeks to introduce Workload Identity Federation resources and datasources to magic modules/terraform. Now that those are merged we were looking forward to using them in our stack, but we now run into this showstopper that we cannot use the federated identities 😢 Fixing this last issue myself will be a real challenge as I have very limited Go experience. @rileykarson is this something you guys will fix or would you otherwise have some guidance where and how I should fix this, so I can attempt a PR |
I intend to get to this! It's taken a little longer to find the time than I expected, though. |
@rileykarson I don’t want to be a PITA, but is there anything we can do to help? This issue is preventing us to roll our workload identity federation, which is a great new feature. |
I had the start of a solution to this which corrected I've relabelled using the |
also ran into |
Are there any workarounds for this (which don't involve null resources with local-exec of "gcloud iam ...")? |
None I'm aware of, the issue is within the resource code so there are no user-side workarounds until we can make a provider fix. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks! |
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
google-beta v3.48.0
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/wvanderdeijl/8095c9f208e362db2d8b8ba031512535
Expected Behavior
The role
roles/iam.workloadIdentityUser
on the service account should have been granted to the principalSet (an identity provided by the new Google Workload Identity Federation feature).Actual Behavior
createIamBindingsMap
ingoogle/iam.go
seems to split a member in its "type" (the part before :) and the "value". It then converts the value to lowercase. See https://github.com/hashicorp/terraform-provider-google/blob/master/google/iam.go#L232This converts my request to add
principalSet://iam.googleapis.com/projects/1066737951711/locations/global/workloadIdentityPools/example-pool/attribute.aws_role/arn:aws:sts::999999999999:assumed-role/some-eu-central-1-lambdaRole
into
principalSet://iam.googleapis.com/projects/1066737951711/locations/global/workloadidentitypools/example-pool/attribute.aws_role/arn:aws:sts::999999999999:assumed-role/some-eu-central-1-lambdarole
This then throws a 400 when applying as the value of a principalSet is case sensitive.
The key element is
workloadIdentityPools
being transformed toworkloadidentitypools
, although the transformation fromlambdaRole
tolambdarole
will not lead to a deployment issue it will lead to a runtime issue as the AWS lambaRole will not be granted access.Steps to Reproduce
terraform apply
Important Factoids
I can use the gcloud cli to demonstrate that the principalSet value is case sensitive:
References
Documentation on Workload Identity Federation from AWS including service account impersonation: https://cloud.google.com/iam/docs/access-resources-aws
There have been more issues and PR's which led to the introduction of case-insensitivity and thus lowercasing the value:
The text was updated successfully, but these errors were encountered: