[Total: 0    Average: 0/5]

Google Cloud Application Default Credentials (ADC) are not credentials. ADC is a strategy to locate Google Cloud Service Account credentials.

If the environment variable GOOGLE_APPLICATION_CREDENTIALS is set, ADC will use the filename that the variable points to for service account credentials. This file is a Google Cloud Service Account credentials file in JSON format. The previous P12 (PFX) certificates are deprecated.

If the environment variable is not set, the default service account is used for credentials if the application running on Compute Engine, App Engine, Kubernetes Engine or Cloud Functions.

If the previous two steps fail to find valid credentials, ADC will fail, and an error occurs.

Also, read my articles Setting up Gcloud with Service Account Credentials and Creating and Authorizing Service Account Credentials with the CLI for more information about Service Account Credentials.

Do not confuse Service Account Credentials with the credentials obtained by gcloud auth application-default login even though application-default looks similar. This command obtains User Account Credentials which Google no longer recommends for Google Cloud access.

User Account Credentials are useful when combining Google Cloud access with other Google services such as Gmail, Drive, Calendar, etc. Another type of Google User Credential is Firebase Authentication.

The example uses ADC to locate and create credentials:

ADC uses similar methods to create credentials using the following examples.

Specify Service Account credentials via the environment:

The previous Python code checks the environment first and will use service_account.json for credentials.

Loading credentials from JSON:

Service account default credentials on Compute Engine:

Service account default credentials on App Engine:

Best practices for managing credentials

Google Cloud Credentials provide access to services and data in the cloud. Protect these credentials.

Do not embed credentials in source code or configuration files. If your application is running in the cloud, attach a service account to your Google Cloud Service and use ADC to obtain these credentials from the instance’s metadata.

Create one set of credentials for testing. Once you are ready to deploy into production, create another set and delete/revoke the testing credentials. This will make sure that no credentials were accidentally leaked or used in the application. Create a new set of credentials for the next phase of testing.

Only transfer credentials over HTTPS or other types of encrypted secure channels. Never transfer credentials in the clear over HTTP.

Do not embed or use long-term credentials in client applications. Use OAuth 2.0 to obtain short-lived temporary credentials. In another article, I show how to take service account credentials and create short-term credentials. This is a good practice when you need to allocate credentials for applications and users.

Periodically rotate credentials. After a grace period revoke the older credentials. This practice will make sure that credentials are in known documented locations (as you will need to change them).

Use a Key Management Service (KMS) or Kubernetes Secrets for encryption keys, certificates, secure configuration variables and anything that needs to be kept private. Build your applications and infrastructure to be secure and free from credential and key leakage.