6

I am currently managing a GCP project, and granted access to a colleague with the Viewer so that he can use the resources on it (mostly downloading files from storage).

I have run into a problem also explained here.

Basically, after running gcloud auth application-default login, they can access the resources but receive a warning

WARNING:                                                                                                                                                                                                                          
Cannot add the project "lixodata" to ADC as the quota project because the account in ADC does not have the "serviceusage.services.use" permission on this project. You might receive a "quota_exceeded" or "API not enabled" error
. Run $ gcloud auth application-default set-quota-project to add a quota project.

This warning is repeated for every script that they run which requires interaction with GCP, which tends to clutter a bit his terminal.

The linked question explains how to make the warnings disappear, but require to grant the user a serviceusage.services.use right, which is not bundled with the default Viewer role.

Reading the documentation did not really clarify things to me: why would I want to use a different billing project than the one I am connected to ?

My question is then two parts:

  • What is the use/risk of granting my colleague the serviceusage.services.use ? Why is it not linked by default with the Viewer role ?
  • Is there any alternative solutions to disable this warning (and this warning only) ?
LoicM
  • 1,786
  • 16
  • 37
  • Try this command **gcloud auth application-default set-quota-project**. https://cloud.google.com/sdk/gcloud/reference/auth/application-default/set-quota-project – John Hanley Jun 24 '22 at 16:13

1 Answers1

10

TL;DR Because otherwise gcloud auth application-default issued credentials consume quota in a Google-owned project which may (not) have the service enabled.

For Google APIs that require authentication and authorization of an "identity", OAuth is used.

In Google's implementation, Google services (specific APIs) must be enabled before use and APIs are enabled (and aggregated) in Google Projects.

There are 2 important types of "identity", (human) users (e.g. gmail.com) and software (sometimes called robot) users. Unassisted (!) software users are identified by Service Accounts.

gcloud is software but it primarily operates on behalf of a (human) user. Because gcloud generally needs to be able to identify its human user (e.g. your gmail.com account), it operates in a delegated manner. gcloud does have its own identity but it (mostly) operates as the human user.

NOTE You can use gcloud with Service Accounts too.

Importantly, gcloud is a so-called installed app. When a user issues gcloud commands, gcloud provides the user's (!) identity and its own identity (called an OAuth Client ID) to a Google Project (!) that Google owns|runs.

NOTE This explains why you can e.g. create projects and enable services with gcloud, because another project (with the correct services enabled) is effecting these API calls on your behalf.

When you develop apps against Google's services, you must decide how the code authenticates to Google. If it represents users, then you'll also need to create a Client ID and route users' requests through that. If it runs as a standalone solution (without user intervention), then it will run as a Service Account.

Google's SDKs include an elegant feature called Application Default Credentials (ADCs). ADCs automate the discovery of Service Account credentials (!), reduce (and thus simplify) code, provide portability and preserve security.

If you can use ADCs, then you should.

This creates (!) a challenge. For developers writing non-user code, how could they test the software without creating a Service Account (and download a key)? The solution was (!) gcloud auth application-default.

When you use gcloud auth application-default, the user (e.g. gmail.com) credentials are used to create credentials that behave just like ADCs. The developer can test their code without having to create a Service Account and keys.

However (!) Google passively (!) discourages the use of gcloud auth application-default.

In part, this is because:

  1. The Google Project that backs requests made using gcloud auth application-default is a Google-owned project not your project; Google is "billed" not you.
  2. The credentials that result have all the powers that the auth'd user's credentials have rather than the (hopefully) more specific (often IAM-controlled) permissions of a Service Account
  3. The Google-owned Project may not have the service that you want to use enabled.
  4. The process is opaque, standalone code may magically authenticate against Google Cloud using ADCs using gcloud auth application-defaut which can be surprising (and shouldn't be).

You should not use gcloud auth application-default credentials for the above reasons.

If you are using gcloud auth application-default credentials you should consider why and choose a better alternative:

  • Either use user credentials directly
  • Or use a Service Account

If off Google Cloud, preferably use a Service Account through Workload Identity Federation

Etienne Neveu
  • 12,604
  • 9
  • 36
  • 59
DazWilkin
  • 32,823
  • 5
  • 47
  • 88
  • Just jumping back to read in details your amazing answer and thank you for it ! I am still a bit puzzled about why google would offer an alternative to service acccount, then discourage it... In my example, my colleague would be the end user, as he (mainly) downloads batch of files from storage in this project via the Python SDK. Your suggestion would then be to create for him (and every other subsequent colleague) a specific service account ? If I am ok with them using the quotas on my project, would giving them the `serviceusage.services.use` privilege be ok ? – LoicM Jul 04 '22 at 10:37
  • It was originally offered as a convenience but has (since) been acknowledged as problematic (and discouraged). You should decide what identity you're looking to manage. If you've many human users then they should be using user accounts. User accounts may be used directly to access Google Cloud resources or indirectly through an installed app. If you need to grant finer identities than per user, then your only alternative is Service Accounts but I suspect you should be using user accounts. – DazWilkin Jul 04 '22 at 15:58
  • What would you recommend is the right approach for developers interacting with Google Cloud resources? `gcloud auth application-default` but set an explicit quota project? – Daniel Compton Feb 15 '23 at 21:10
  • @DazWilkin can you clarify why you think ADC are discouraged or link to a document describing this? Google's documentation explicitly says that you should use ADCs whenever you can, see: https://cloud.google.com/docs/authentication#adc – nioncode Aug 09 '23 at 20:09