How to authorize snapshots for gcloud

[Rick Otten]

I asked this question on StackOverflow yesterday and got no responses.   Not being able to use gcloud to generate and manage snapshots is a frustrating roadblock in our project.

--

I have:

1. Initialized gcloud.
   

gcloud init

      2. Generated a key for a service account from the IAM console. (web interface)

         -> The service account has "Editor" privileges for my project.

1.       3.  Authorized the service account.

   gcloud auth activate-service-account --key-file mykeyfile

However, when I try to access the snapshots management features:

$  gcloud compute snapshots list
ERROR: (gcloud.compute.snapshots.list) Some requests did not succeed:
 - Insufficient Permission

I can't find anywhere in the documentation specifically how I grant permission to gcloud to allow it to do this.  ( gcloud compute disks snapshot  fails with the same error too.) 

Any tips?

[Carlos (Cloud Platform Support)]

Hi Rick,

I tried to reproduce your issue but it worked for me. Here are the steps I followed:

1. In my case I created a VM in my project to run gcloud from it. For testing purposes I selected ¨Set access for each API¨ during the VM creation. There I made sure that ¨Compute¨ was set to none. In that way I limited access to the default service account linked to the VM to compute resources.

2. I SSH in the VM and made some pre-check tests.

gcloud auth list

Credentialed Accounts:

- 3xxxxxxxx...@developer.gserviceaccount.com ACTIVE

To set the active account, run:

   $ gcloud config set account `ACCOUNT`

myuser@instance-5:~$ gcloud compute snapshots list

ERROR: (gcloud.compute.snapshots.list) Some requests did not succeed:

- Insufficient Permission

3) I created another service account, gave it ¨Editor¨ permissions and generated the key.

4) I uploaded the key to my VM and set this account to work with gcloud.

myuser@instance-5:~$ gcloud auth activate-service-account --key-file mykeyfile.json

Activated service account credentials for: [customse...@xxxxxxtest.iam.gserviceaccount.com]

myuser@instance-5:~$ gcloud auth list

Credentialed Accounts:

- 3xxxxxxxx...@developer.gserviceaccount.com

- customse...@xxxxxtest.iam.gserviceaccount.com ACTIVE

gcloud compute snapshots list

NAME           DISK_SIZE_GB  SRC_DISK                           STATUS

xxxxxxxxxx  10            us-central1-f/disks/cpaneltest     READY

I would suggest trying to run a similar test.  Are you running gcloud from a GCE VM or your own computer? Additionally, you can confirm the project and the account used by gcloud using:

¨gcloud auth list¨ and ¨gcloud config list¨. If you are using a non-default service account and it has Editor permissions that should be enough. You must also check that gcloud is configured to use the right project.  

[Rick Otten]

I was using the default account.

I created a new service account, gave it the editor role, activated and selected the account as shown below and it worked.  It was not obvious that the default account had these privileges disabled for some unknown reason.

I'm good to go now.  Thanks for the help!

(I'll update the stackoverflow question too.)

[Carlos (Cloud Platform Support)]

I am glad it worked. The default service account is tightly linked to GCE instances and the access scope they can have. Working with the default service account and IAM permissions can be a little tricky as explained here. 

[Eric Bahna]

Hi Rick,

I'm sorry for the frustration. Were you running gcloud within a VM or on a physical machine?

Trying to understand what happened so we can figure out where to improve things.

Thanks,

Eric

Product Manager, Compute Engine

On Thu, Nov 3, 2016 at 1:59 PM, 'Carlos (Cloud Platform Support)' via gce-discussion <gce-discussion@googlegroups.com> wrote:

I am glad it worked. The default service account is tightly linked to GCE instances and the access scope they can have. Working with the default service account and IAM permissions can be a little tricky as explained here. 

--
© 2016 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-discussion@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.
---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to gce-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/a608179a-0991-46c2-8241-d39bba5dd3dd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Bahna]

Below is a bit of background for the benefit of other folks who have a similar question when running gcloud in a VM. Below that, there's an opportunity to voice your feedback! :)

In order for gcloud in a VM to call an API method as the VM's service account, two things need to be true:

1. The service account needs to have permission to call the method. The default service account had the Editor role on the project so this was not the limiting factor.
   
2. The VM needs to be configured with a scope that provides access to the API method. By default, VMs have scopes that give them access to the APIs listed at https://cloud.google.com/compute/docs/access/service-accounts#compute_engine_default_service_account. The Compute Engine API is not one of those, so this was the limiting factor.

If you provide a key file for another service account (i.e., not the one the instance is configured to run as), then the instance's scopes don't apply. That's why the other service account worked. This is not obvious from our documentation and I've filed a bug to improve this.

I'd appreciate feedback on a few design approaches we're considering to simplify API access from within a VM. Do you have a preference amongst these three options for the default behavior of VMs?

1. VMs could access the same set of commonly used Google Cloud APIs by default as they can today. 
   The difference is that there would be no need to consider scopes. Instead of the service account having the Editor role by default, it would be granted a set of predefined IAM roles. Each of these roles have less access than Editor, but combined they would give access to the same APIs as today (e.g., VM could write to Cloud Monitoring, read from Cloud Storage). 
   
   With this behavior, you could grant the service account the Compute Instance Admin role on the project in order for "gcloud compute snapshots list" to work inside the VM. No need to create another service account.
   
   
2. VMs could access all Google Cloud APIs by default.
   With this behavior, calling "gcloud compute snapshots list" would've returned the snapshots without you needing to grant any additional IAM roles, provide any key file or, create another service account.
   
   
3. VMs could access no Google Cloud APIs by default.
   With this behavior, you would create a service account and grant itthe Compute Instance Admin IAM role on the project, then configure the instance to run as that service account.

We're still evaluating these and I'd like your input to influence our decision.

Thanks,

Eric

[chris marx]

My preference would be that when you spin up a compute instance for the time, and you see that the gcloud sdk is already installed, and try setting up automatic snapshots (because why isn't supported automatically through the console?), and you get permission errors, that those errors are more informative and at least tell you what you need to do to enable things. Currently, you get a vague permission error. It's very unclear that the permissions in this case aren't even about the IAM roles for the service account, but instead about the VM permissions itself-

Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-dis...@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.

---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussio...@googlegroups.com.

To post to this group, send email to gce-dis...@googlegroups.com.

[Eric Bahna]

Hi Chris,

You're right - that error message doesn't make it clear that the instance's scopes are the problem rather than the service account's IAM permissions. I've filed a bug for us to improve that.

If the instance has the necessary scopes and the service account doesn't have the necessary IAM permissions, gcloud returns a more detailed error message describing which permission is missing on which resource.

$ gcloud compute snapshots listERROR: (gcloud.compute.snapshots.list) Some requests did not succeed: - Required 'compute.snapshots.list' permission for 'projects/[PROJECT-NAME]'

Thanks,

Eric

--
© 2017 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-discussion@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.

---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to gce-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/35ef6943-e96b-4618-808a-5be1f0b52fc5%40googlegroups.com.