Drux
Drux

Reputation: 12660

service account does not have storage.objects.get access for Google Cloud Storage

I have created a service account in Google Cloud Console and selected role Storage / Storage Admin (i.e. full control of GCS resources).

gcloud projects get-iam-policy my_project seems to indicate that the role was actually selected:

- members:
  - serviceAccount:my_sa@my_project.iam.gserviceaccount.com
  role: roles/storage.admin
- members:
  - serviceAccount:my_sa@my_project.iam.gserviceaccount.com
  role: roles/storage.objectAdmin
- members:
  - serviceAccount:my_sa@my_project.iam.gserviceaccount.com
  role: roles/storage.objectCreator

And documentation clearly indicates that role roles/storage.admin comprises permissions storage.objects.* (as well as storage.buckets.*).

But when I try using that service account in conjunction with the Google Cloud Storage Client Library for Python, I receive this error message:

my_sa@my_project.iam.gserviceaccount.com does not have storage.objects.get access to my_project/my_bucket.

So why would the selected role not be sufficient in this context?

Upvotes: 81

Views: 154356

Answers (8)

Kittichote Chain
Kittichote Chain

Reputation: 681

For me, it worked after I added the associated email in the IAM page by the folowing steps. ChatGPT helps me on this btw.

  1. Go to the Google Cloud Console at https://console.cloud.google.com/.
  2. Select the project associated with your Firebase project.
  3. Open the "IAM & admin" page from the left-hand menu.
  4. Click the "ADD" button to add a new member to the project.
  5. Enter the email address. For me it was in the following format. [email protected]
  6. Select the role Storage Object Creator or Storage Object Admin from the dropdown menu.
  7. Click the "SAVE" button to save the changes.

Upvotes: 3

fgd
fgd

Reputation: 51

in my case, after the service account is created, interface returns error: "service account does not have storage.objects.get access for Google Cloud Storage".

But, When I tried again the next day, everything was fine :)

Upvotes: 0

Rens
Rens

Reputation: 745

I got this error when I copied a cloud function from another project because I forgot to update the storage bucket. Silly mistake.

admin.initializeApp({
  storageBucket: "gs://*****.appspot.com",
});

Upvotes: 1

Broda Noel
Broda Noel

Reputation: 1960

I just realized this happens some times when you are just creating the Firebase/Firestore/Storage project by first time.

If you got this error in your first installation/deploy/setup, just wait 1 minute and try again. Seems like some delays in the Google Cloud deploys/serving are responsible of this.

Upvotes: 4

0Pat
0Pat

Reputation: 412

It's worth noting, that you need to wait up to a few minutes for permissions to be working in case you just assigned them. At least that's what happened to me after:

gcloud projects add-iam-policy-binding xxx --member
"serviceAccount:[email protected]" --role "roles/storage.objectViewer"

Upvotes: 27

Yairopro
Yairopro

Reputation: 10340

For me, it was because deployed with the "default-bucket" as parameter needed for the storage emulator.

admin.storage().bucket('default-bucket'); // do not deploy that

To fix it, I set the default bucket name at the initialization of the firebase admin.

const admin = require('firebase-admin');

const config = process.env.FUNCTIONS_EMULATOR ? {
    storageBucket: 'default-bucket',
} : {
    storageBucket: 'YOUT_FIREBASE_STORAGE_BUCKET',
};

admin.initializeApp(config);

const bucket = admin.storage().bucket();

Upvotes: 1

nour
nour

Reputation: 608

Go to your bucket's permissions section and open add permissions section for your bucket. For example, insufficient service, which gcloud tells you, is;

[email protected] 

Add this service as user then give these roles;

  • Cloud Storage - Storage Admin
  • Cloud Storage - Storage Object Admin
  • Cloud Storage - Storage Object Creator

Then you should have sufficient permissions to make changes on your bucket.

Upvotes: 45

Drux
Drux

Reputation: 12660

The problem was apparently that the service account was associated with too many roles, perhaps as a results of previous configuration attempts.

These steps resolved the issue:

  • removed all (three) roles for the offending service account (member) my_sa under IAM & Admin / IAM
  • deleted my_sa under IAM & Admin / Service accounts
  • recreated my_sa (again with role Storage / Storage Admin)

Effects are like this:

  • my_sa shows up with one role (Storage Admin) under IAM & Admin / IAM
  • my_sa shows up as member under Storage / Browser / my_bucket / Edit bucket permissions

Upvotes: 28

Related Questions