Authentication

In order to interact with Google Cloud resources, users must authenticate against Google Cloud and grant authorization to the tools in the Google Cloud SDK. If you've just run the gcloud init command, your machine should be fully authorized. When using the Google Cloud Shell, your session will be authorized against the current project by default. Google uses OAuth 2.0 for API access. When a user authorizes the SDK, Google will store an access token for that user locally for later use. The gcloud CLI contains tools for managing authentication and authorization under the gcloud auth command group.

Login is a straightforward process; simply run gcloud auth login to open a new browser window and confirm the authorization request. If your session is not aware of a display (as with headless servers), you will be presented with a URL to perform an offline login. Simply copy this link into your browser, retrieve the verification code, and paste the code into your shell. The offline flow can be manually triggered by passing the --no-launch-browser flag.

The Google Cloud SDK has an established process for storing authentication tokens on a system. For local development, the default location is in $HOME/.config/gcloud for Mac and Linux and $HOME\AppData\Roaming\gcloud for Windows. These credentials should be considered sensitive data.

Alternatively, users can assume the identity of a service account to take actions on that service account's behalf. One use of this is to temporarily modify or elevate user privileges. Doing this requires having a local copy of the service account's key file (a topic covered later in this chapter). To assume the identity of a service account, run gcloud auth activate-service-account --key-file=</path/to/key/file>.

You can verify that you are acting on behalf of the service account by running gcloud auth list, which will show your available accounts on your machine, as well as which is currently active.

Whether running in the cloud or on your local machine, Google Cloud SDKs and libraries are able to load credentials from known default locations, generally referred to as application default credentials. This is extremely useful when building an application to interact with Google services. For example, let's suppose you have a Java application that needs to interact with data on Datastore. When running locally, the Google Cloud Datastore API for Java is able to locate and authenticate using the application-default credentials on your machine. When you deploy the application to Google App Engine, the same method will work here to load the application-default credentials available in the App Engine environment.

During local development, it is often preferable to have Google SDKs and libraries load a specific application-default credential. To do this, users can set the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to a valid credentials file. This will usually be a service account's JSON key file, but you may instead use your own user credentials by running gcloud auth application-default login. This default credential can then be removed by running gcloud auth application-default revoke.