-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
#843: Add policy support to storage buckets #1190
Conversation
You'll need to add documentation for this under Please be sure to explicitly call out the legacy roles that might be auto-removed! As for testing, let me look into that and get back to you. |
You'll just need to add a simple test to https://github.com/terraform-providers/terraform-provider-google/blob/master/google/resource_storage_bucket_iam_test.go - similar to what's already there. |
@ndmckinley I adressed the documentation and test. It also explains what happens if the legacy roles are removed and how that can be restored. The test is alike to IAM Binding. As far as i can tell this policy is now on par with the other two methods of assigning permissions. |
|
||
* `google_storage_bucket_iam_binding`: Authoritative for a given role. Updates the IAM policy to grant a role to a list of members. Other roles within the IAM policy for the storage bucket are preserved. | ||
* `google_storage_bucket_iam_member`: Non-authoritative. Updates the IAM policy to grant a role to a new member. Other members for the role for the storage bucket are preserved. | ||
* `google_storage_bucket_iam_policy`: Authoritative for a given policy. Resets any other permission on the bucket, including default Google permissions that you inherit upon bucket creation. See the usage example on how to handle this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you make this a little bit more cautious? "Setting a policy removes all other permissions on the bucket, and if done incorrectly, there's a real chance you will lock yourself out of the bucket. If possible for your use case, using multiple google_storage_bucket_iam_binding
resources will be much safer.", or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, running the tests now. One minor doc tweak I'd like to ask for.
Bummer:
|
I updated the readme, and i think i found the issue with the test. When running the PR against real google cloud it works, but i have not yet replicated the acceptance test suite environment. |
I'll give it another run. :) |
} | ||
|
||
resource "google_storage_bucket_iam_policy" "fooPolicy" { | ||
bucket = "${google_storage_bucket.%s}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the problem - you'll need to append .name
. You can't use the entire resource here, you need to access the right attribute on the resource, which is .name
.
Sorry, no dice:
I commented the problem in a review. |
i got and fixed it, next time i'll use proper search/replace to go from actual files to templated test versions. |
@@ -144,7 +144,7 @@ data "google_iam_policy" "fooPolicy" { | |||
} | |||
|
|||
resource "google_storage_bucket_iam_policy" "foo" { | |||
bucket = "${google_storage_bucket.%s}" | |||
bucket = "${google_storage_bucket.%s.name}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still isn't quite right - you just want "${google_storage_bucket.bucket.name}", right? You just want the name of that bucket?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
%s
here is the name of the bucket (the value of google_storage_bucket.bucket.name
), right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resource "google_storage_bucket" "bolcom-sbx-kroonapp-010-kroon" {
name = "bolcom-sbx-kroonapp-010-kroon"
project = "bolcom-sbx-kroonapp-010"
location = "EUROPE-WEST1"
storage_class = "REGIONAL"
force_destroy = false
labels = {
opex = "teamprovisioning"
stores_pii_data = "false"
}
versioning = {
enabled = false
}
}
data "google_iam_policy" "kroontest" {
binding {
role = "roles/storage.objectAdmin"
members = [
"user:[email protected]",
]
}
}
resource "google_storage_bucket_iam_policy" "kroontest" {
bucket = "${google_storage_bucket.bolcom-sbx-kroonapp-010-kroon.name}"
policy_data = "${data.google_iam_policy.kroontest.policy_data}"
}
This is the generated terraform file that works for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, because the bucket resource is called "bolcom-sbx-kroonapp-010-kroon", but that's also its name attribute. In the test, the bucket resource is called "bucket", but its name attribute is a random string. You want to access that random string here. I'm rerunning the tests now.
The bucket's resource name isn't the same as the bucket name, which is the problem. Sorry! |
@ndmckinley I have run the integration tests myself. It turns out that removing all policies (i.e. setting an empty iam policy) is non trivial. I found that gsutil is able to do this by just setting the Etag value and i copied this behaviour. |
I'll run the tests now. |
Sorry:
If I'm reading that right, I think you can configure it when you create the bucket. |
@ndmckinley I ran the test in a separate cloud, so i ran under 'Owner' permissions. What user can i expect for these integration tests? It probably means i have to set up roles and permissions for the service account user first which makes the test config a dependant on other parts of the application as well. |
Ah! Sorry, this completely fell off my radar and I didn't find it again until I did a sweep of open PRs. Sorry about that! @paddycarver might be able to comment on the permission setup in our CI system and how you can make sure that the user has permission to read from the buckets. I'll look into it myself as well and try to get back to you with that answer. |
Yeah, if I'm reading this right, you can probably just add that service account |
I'm not following here, sorry--why should a contributor have to add our service account to anything? Our service account should have all the permissions it needs when running tests against our CI environment. If it doesn't, I would say that's a problem with the CI setup, not with the PR, and if we think it's a permissions problem, I can investigate the CI setup and make sure things are right. |
I think I'm a little confused myself, but let's see if I understand: Since the new test applies an entire IAM policy to the bucket, it removes the service account's access to that bucket (since the service account is not in the policy). To work around that so that the test can pass, we need to add the service account to the policy in the test? That's how I understand it, or my theory at least. |
i run with the acceptance with the following environment variables set:
You are right that there it's non standard to delete the bucket which has it's policy removed. However it's not impossible, but i can imagine that my use of GOOGLE_USE_DEFAULT_CREDENTIALS which makes me owner on the project has some effect. |
Could we just use an environment variable to pass in the service account/email address running the tests, and then inject that into the policy with the appropriate rights? That would sidestep the issue, I believe? |
That's a good idea, thanks. @ReneKroon - sorry to keep asking for more here. I'm happy to add that if you'd prefer not to, you've definitely spent enough time on this already, just let me know. |
@ndmckinley Well i've learned at least to manage the full development cycle with this change :-) I would like to ask you to make this CI related adjustment. It will be a lot of roundtrips again if something would not work right away, since i have no insight into your CI infrastructure. |
Okay, there we go. @ReneKroon please be aware! To continue with this PR I had to push to your master branch because that's the branch you used to open the PR. Because of some merge conflicts, I had to merge master into the PR ... so your master branch just jumped by a couple versions. If you need your old master branch back, you should be able to do this:
Of course that'll screw up this PR, but I still have all this stuff on my fork, so you don't need to worry about that - I'll just open a new one if you need that. |
Test passed, but since my code's in here, I probably ought to get another review on that stuff. Hang on, I'll get this merged yet. :) |
```hcl | ||
resource "google_storage_bucket_iam_policy" "member" { | ||
bucket = "your-bucket-name" | ||
policy_data = "policy_data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a string snuck in here- I think you meant to have this refer to a policy data source.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
] | ||
} | ||
|
||
binding { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: tabs/spaces consistency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
} | ||
|
||
|
||
data "google_iam_policy" "fooPolicy" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: let's aim for consistency between the naming case for the resources, so this should be foo-policy and then below would be bucket-binding
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Storage bucket tests all pass. |
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 👉 [email protected]. Thanks! |
#843 is fixed by this line, after the consensus that legacy roles should not be implicitly supported.
Since this is my first commit to the project, i'd like to have some pointers on testing. For example this change only wraps existing policy functionality on a bucket. Does this require a separate testcase anyway?
Since using this feature could remove legacy rows, how would a documentation update for this change work?
Thanks in advance,
Rene Kroon