Best auth strategy for GCP client tool

Question

I want to build a client gcp tool in python.

I want to avoid invocations of the glcoud tool via subprocess so I opt for sdk client library invocations.

According to the docs as also this very and comprehensive article, there are two options for auth:

a) using the application default credentials (i.e. the ones used by gcloud under the hood)

b) using a service account and pointing the app to the corresponding .json file.

I have already tried the (a) and got the following warning:

UserWarning: Your application has authenticated using end user credentials from Google Cloud SDK. We recommend that most server applications use service accounts instead. If your application continues to use end user credentials from Cloud SDK, you might receive a "quota exceeded" or "API not enabled" error. For more information about service accounts, see https://cloud.google.com/docs/authentication/
warnings.warn(_CLOUD_SDK_CREDENTIALS_WARNING)

If I use app default creds, this makes it easy since each end user the app will be distributed to, will have this .json file a source of truth for his/her auth process. However, the app may encounter the above quota exceeded error.

In the other case, (service account specific credentials) I assume I will have to provide instructions to each developer to issue a json file that corresponds to a service account with the exact same permission as his/hers. And what about the update process? What happens each time a user gets assigned / revoked some permissions? How this json stays in sync?

Any advice about this would be highly appreciated.

Answer 1

There are several types of application default credentials (ADC): User Account and Service Account and variations of those. The warning message in your question means that you set up the SDK CLI with user account credentials (gcloud auth login). I recommend switching to service account credentials.

This command will setup the CLI with a service account. You will need your Project ID and service account JSON file.

gcloud auth activate-service-account test@PROJECT_ID.iam.gserviceaccount.com --key-file=service_account.json

I wrote an article that goes into detail on how to set up the CLI:

Setting up Gcloud with Service Account Credentials

Why is Google giving you a warning:

• Authorizing User Credentials requires more effort on Google's backend services.
• User Account credentials require human interaction to create.
• The Refresh Token is often stored by software on the client or backends. This creates a security hole.
• Software should use machine-to-machine authentication with limited permissions (scopes). User credentials typically are issued with too many permissions for the API calls being made. This again is a security issue.
• Google has decided that User Credentials will not be allowed to have the scopes required to access many Google Cloud Platform services. This is very apparent when creating OAuth Clients and you receive a big warning about verification. There is a strong risk that Google will stop allowing user credentials for cloud services. It is better to use the supported and official method of a service account and not face this issue in the future.

However, given the above details, your use case is providing your users with credentials. This is not a good idea. I would continue to use User Credentials talking to your web frontend. Your web frontend uses a service account that the user never sees and provides the final service (API) access.

[UPDATE]

I just noticed your comment that you are developing your own CLI. Without more details on what projects/services this CLI will be accessing you might consider using user credentials that talk to your service which issues an Access Token to the user. This token is only valid for one hour. You can support refreshing this token in your code. This gives you the ability to use user authentication, control service account usage and still maintain good security. Notice that I am trying to steer you away from distributing service account files directly to users. If these users are your own employees, this is less of a problem. For people not under your control think carefully.

[END UPDATE]

I will try to provide details and advice on your questions. Do consider my previous comments while deciding the best strategy for you.

In the other case, (service account specific credentials) I assume I will have to provide instructions to each developer to issue a json file that corresponds to a service account with the exact same permission as his/hers.

If I were to write an application that used service account credentials, I would create a method to load/install the credentials. Just provide a file and tell them to do this step in the program. However, you have an issue. It is not a good idea to distribute the same service account to all users. How do you handle revoking, etc? Google Cloud Platform service accounts are not designed to be distributed uniquely to more than a few dozen or hundreds users per project.

And what about the update process?

Service account credential JSON key files do not expire. The tokens created from the service account do expire but this is managed by Google client libraries or in your own code to automatically refresh them.

What happens each time a user gets assigned/revoked some permissions? How this JSON stay in sync?

The service account file does not contain permissions. These are stored in Google Cloud IAM. Once you modify the roles assigned to a service account, they are transparently applied globally within a few minutes.

Answer 2

If the tool is only expected to be used interactively (e.g. replacing gcloud), its likely fine to use the default credentials, as the usage will be low.

That said, creating a key for a service account is a pretty striaghtforward operation in either the console or via gcloud and the API makes it reasonably easy to consume the key -- you basically set a GOOGLE_APPLICATION_CREDENTIALS environment variable. See more at this page. Using service accounts also allows you to assign exactly the roles that are required, rather than operating with the broad permissions that a user account might have, and this reduces the possibility of mistakes where the code does something it shouldn't.