terraform-provider-google: Potential Race Condition When Apply Google Project IAM Policy

This issue was originally opened by @zachgersh as hashicorp/terraform#12291. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

0.85+

Affected Resource(s)

google_projec_iam_policy

Terraform Configuration Files

None provided. Totally can work up an example if needed.

Expected Behavior

I should be able to remove/add members to the policy

Actual Behavior

I get random permission denied errors due to the fact that the policy has become out of date (a member was added or removed before the policy was destroyed).

Spoke to @evandbrown a bit about this and I am unsure if restoring a saved copy of the previous policy that is stored in your tfstate file is the right way to go. It would seem that anyone with multiple environments / policy changes in the same project would end up hitting this problem.

Steps to Reproduce

create two different policies in the same GCP project
start to teardown one and then begin tearing down the other
watch it fail

cc @paddyforan as well whose been looking over a bunch of my GCP changes.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 15 (6 by maintainers)

Commits related to this issue

Merge pull request #58 from modular-magician/codegen-pr-630 Generate DefaultObjectAccessControl in Terraform — committed to luis-silva/terraform-provider-google by rileykarson 6 years ago
Merge pull request #58 from modular-magician/codegen-pr-630 Generate DefaultObjectAccessControl in Terraform — committed to luis-silva/terraform-provider-google by rileykarson 6 years ago

Most upvoted comments

The three google_project_iam_* resources all control different levels of the same thing.

google_project_iam_policy controls the entire project. It ensures that no accounts are set on any roles except the ones it defines.
google_project_iam_binding controls a specific role within the policy. It ensures that no accounts except the ones it defines are set on only the one role it controls. Two or more google_project_iam_bindings can be used for the same project, but only if they’re controlling different roles.
google_project_iam_member controls a specific member on a specific role in the policy. It ensures that the member is part of the role, but doesn’t care if other members are on that role or not.

If you use google_project_iam_member or google_project_iam_binding, you shouldn’t use google_project_iam_policy.

If you use google_project_iam_member, you shouldn’t use a google_project_iam_binding for the same role, though other google_project_iam_members on the same role are fine. And google_project_iam_bindings on different roles are fine.

If you use google_project_iam_binding, you shouldn’t use a google_project_iam_binding or a google_project_iam_member on the same role.

paddycarver on Oct 7, 2017