I am an organisation of one person, just me. I've been using GCS with no problem for a few years. Today I've created a new bucket, and am currently using gsutil to populate it, with no obvious problems.
In the GCS web app I've just tried to click into the bucket via the Storage browser, just to verify it was being populated, and was told
Additional permissions required to list objects in this bucket: Ask a project or bucket owner to grant you 'storage.buckets.list' permissions (e.g. by giving your account the IAM Storage Object Viewer role).
Ok... but I created it? Whatever, I'll click on the menu button (three vertical dots) next to the bucket name and select Edit bucket permissions.
You do not have permission to view the permissions of the selected resource
Right...
Any ideas?!
You figured it out based on your comments. To reduce future guesswork, a really good reference exists for figuring out what roles get which permissions.
Related
I have created a bucket which has some files. I want my team to access that bucket. I tried creating a policy and adding the users but still, the team can't see the bucket.
The first step is that you need to invite the users in your team to your account. You can do that in the UI "Manage -> Access -> Users".
Your team member needs to accept the invitation to your account and should then be able to switch to your account using the account switcher on the top right of her/his UI.
Now you can follow these steps to give bucket permissions to the user(s) in your account: https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam-bucket-permissions
Once you feel comfortable with this, you can have a look into IAM Access Groups. Using IAM Access Groups you don't need to manage each individual user in your team and add permissions to the user. With IAM Access Groups you add the necessary permissions to the group and then add all users that need these permissions to the group.
I hope this helped.
Tried sharing a bucket with a colleague
Initially I added the "Storage.Object.Viewer" role, and sent the link https://console.cloud.google.com/storage/browser/bucket_name/
However on opening the link the following error was received:
You need the storage.objects.list permission to list objects in this
bucket. Ask a project or bucket owner to give you this permission and
try again.
I added more roles, and finally gave admin rights, but kept getting the same error.
How can I share a bucket with all files? specifically I would like to share with read-only permissions
Although a solution has been discovered for this issue, I'm going to summarise some relevant information which may be useful to someone who stumbles on a similar issue.
Project information isn't required in requests to storage buckets, because bucket names are required to be globally unique on Google Cloud Platform, which means if you specify a bucket name in any request, the request will point to the correct bucket no matter what project it resides within, so permissions for a given user to access that bucket must have been set-up in some capacity.
To allow users to list objects in a bucket, they must have been assigned a role with the storage.objects.list permission. Minimal role's that allow the listing of objects in buckets include:
Storage Object Viewer
Which allows users to view objects and their metadata, except for ACLs. They can also list the objects in a bucket.
Project Viewer
This roles also provides users permission to view other resources in the project. In terms of Cloud Storage, users can list buckets. They can also view bucket metadata, excluding ACLs, when listing.This role can only be applied to a project.
There are other storage specific roles which allow users to list objects in buckets, but to also have other authorisation, for example, to edit/create/delete objects. They include:
Storage Object Admin
Users have full control over objects, including listing, creating, viewing, and deleting objects.
Storage Admin
Users have full control of buckets and objects.
For more information on Cloud Storage IAM Roles please see here.
Assuming the google account used to access the URL by your colleague is the one you gave permissions to, you need to also grant "Viewer" role at the project level else he wouldn't be able to login to the GCP console and access the bucket.
Initial Question
I'm trying to do something that I think is somewhat simple, but I can't seem to get it nailed down correctly. I've been trying to create a bucket on GCS that is accessible to anyone in my GSuite organization, but not the larger internet.
I've created an org#mydomain.com group and added all users. I then granted that user permission to view the file in the bucket, but it always says access denied. If the file is marked public then it's accessible without issue. How do I get this setup?
Additional Information
I have transferred the project and bucket to my organization
I have setup the index and 404 pages
If marked public, everything works as expected
When I check the permissions of individual files, I don't see anything inherited or more specific than the general project security settings.
I added the Storage Object Viewer permission to the bucket for my org#domain.com group
When trying to access a file, I get the following response:
<Error>
<Code>AccessDenied</Code>
<Message>Access denied.</Message>
<Details>
Anonymous caller does not have storage.objects.get access to compliance.microcimaging.com/test_xray.jpg.
</Details>
</Error>
So, thinking that it might be thinking I was using a different account, I opened an Incognito Window, logged in as my organization, then attempted to access. That gave me the same message.
I tried adding the org#domain.com user to a single file, which resulted in the same error. I then attempted to add my personal username to the file, which resulted in the same error.
Permission errors have got to be the MOST BORING errors!
Seeing that you already created a Google group you can accomplish this quite easily.
On Google Cloud Platform Console go to "Storage -> Browser", and on your bucket, on the menu on the right select "edit bucket permissions".
On "Add members" put org#mydomain.com and give the role of "Storage -> Storage Object Viewer" to give the whole group read only permissions when authenticated or any other permission combination you need.
Alternatively see this documentation about how to set IAM policies on a Gsuite domain, so you can even skip the group part and set access control policies to the Google Cloud products for your domain as a whole.
In our project, we have a group of people which should have full access to ONLY a bucket and they should not see other buckets or the object on the other buckets.
so, i changed the permission of the bucket, and i added the users as Storage Admin for that specific bucket (not for whole project).
In this case, when they use console/Storage they see the following message:
But when they open cloud Shell and they use Gsutil, they can access to the bucket objects (no access to other buckets).
Is this a bug on the interface of Console/storage?
This is not a bug, but it is a subtlety of the Console. In order to access a bucket from the Console, you typically navigate to it using the Browser, which is what appears you attempt in the screenshot. This fails, though, because to do this you need permission to list buckets for a project, even if you otherwise have free reign to work within the bucket.
There are three ways to deal with this:
1) Give your users the Viewer permission for the project that contains the bucket. There are pros and cons to this. I'd say it's probably not worth going this route (though not as much because your users will see other buckets - bucket namespace is publicly viewable anyway - but because doing so brings up some additional permission nuances you probably don't want to deal with).
2) Link directly to the desired bucket, thus avoiding the "listing buckets" portion of the Console. The URL for a bucket has the form: console.cloud.google.com/storage/browser/[BUCKET_NAME]. I believe this will work without any additional modifications to your permissions.
3) Create a custom role that only contains the storage.buckets.list permission, and use that role on the project for affected users.
I'm having an issue with the CloudSQL connection on a specific account.
If I use account A to preview the project it works fine, yet account B with the exact same cloudSQL credentials is unable to preview, account B is the owner of the project.
They both have the same IAM roles in the cloudSQL project and both accounts were able to preview last week.
I've tried deleting cache, navigation files and another browser using account B.
Any ideas?
I'm going to add a new answer to resolve this because I think it's worthwhile to keep the previous answer and discussion intact. The issue here was that the accounts which did not work have the "Viewer" role in the IAM & Admin section of the Google Cloud SQL project. The Viewer role gives (among other permissions) read access to Cloud SQL, but not write access.
The best role to use if restricted access is required, but they need full access to read/write SQL, is the Google Cloud SQL Client role. See https://cloud.google.com/sql/docs/mysql/project-access-control for more information on roles and what access they give.
Thanks for Juan for help tracking all this down.
Edit: It's also worth mentioning that the reason this works in the Editor, but not in Preview/Deployments is the editor is explicitly whitelisted for access (as one of the steps we ask you to do in the documentation), so it doesn't use role permissions for a particular account, while access through your deployments is not explicitly whitelisted in this way, so role permissions are enforced.
Do the following, in Incognito windows in Chrome (to make sure you're using the correct account):
1) Log into the account it is not working with.
2) In the Google Cloud SQL tab, press Update, and enter new credentials, wait for it to finish, and then try to preview.
3) Assuming this does not work, now close your incognito window and log into the account it is working with.
4) Repeat step #2 (entering new the same credentials).
If you cannot access it after step #2, but you can access on step #4, and if both users can modify the SQL model from App Maker, then there is a probably strange bug we (the App Maker team) needs to look into.