GCP Authentication: The Ultimate Practical Guide to the gcloud CLI & Google Cloud ADC

When you work with the Google Cloud Platform, you’ll inevitably encounter various methods of GCP authentication. It’s often not clear at first glance which method is the right one for a given situation. In this article, we’ll give you a structured overview of all gcloud authentication methods, explain the core concept behind the two main groups, and then use five real-world scenarios to show you when it’s best to use each method.

This article provides insights on:

• Two Groups of GCP Authentication
• Exceptions and Special Cases
• An Overview of the 7 Methods
• GCP Authentication in Practice: 5 Use Cases
• Overview: Check and Reset Authentication Status

Two Groups of GCP Authentication

When we talk about GCP authentication, we generally distinguish between two areas: authentication for gcloud CLI commands and authentication for your code.

Group 1: gcloud CLI commands

This first group applies to all subsequent commands in the gcloud CLI. A typical example of resource management is: gcloud sql instances create …

Group 2: Application Default Credentials (ADC) for Code

The second group is used in entirely different situations, namely when your code communicates via the Google Cloud SDK. For example, if you’re using Node.js, the Cloud Storage SDK loads the google-auth-library in the background. This library then uses your Google Cloud ADC user for GCP authentication.

The following line of code imports the Google Cloud Storage client, which automatically relies on the ADC workflow. This authenticates your application without requiring you to hard-code any credentials:

const { Storage } = require('@google-cloud/storage');

In addition, this method is also used by Terraform. A command such as ` terraform apply ` also applies changes based on Google Cloud ADC. While these two groups do not cover 100% of all special cases, they do include the most important scenarios.

Exceptions and Special Cases

One interesting example is the Cloud SQL Proxy. If you run it using the gcloud CLI (

gcloud alpha cloud-sql proxy …

, the command ` gcloud auth login`

authenticated users. However, if you run it using the local binary

cloud-sql-proxy my-project:us-central1:my-db-instance

The Google Cloud ADC workflow starts.

Another good example is Google’s VS Code extension “Cloud Code.” Intuitively, you might expect that gcloud CLI commands—and thus the gcloud user—would be used here. In reality, however, Skaffold and gcloud CLI commands run in the background, which is why this extension also relies on Google Cloud ADC.

Abbreviations / Abbreviations

• SA… Service Account
• ADC… Application Default Credentials (see our previous article on Google APIs and service account impersonation)

In the next section, we’ll apply these methods to real-world use cases—from the initial setup of the infrastructure all the way through to deployment in production.

GCP Authentication in Practice: 5 Use Cases

Now that we’ve covered the theory, let’s look at five specific scenarios to see which method should be used in each phase of a real-world project—from the initial setup of the infrastructure to production deployment on a third-party hosting platform.

Using the example of a tech lead and a developer setting up a Cloud Run application with a Cloud SQL database, we’ll show how different authentication methods interact throughout the entire project lifecycle: from the initial infrastructure setup (ID 5), through the initial resource setup via the gcloud CLI (ID 1), local development with service account impersonation (ID 6), one-time impersonation for deployment (ID 4), persistent impersonation for debugging (ID 2), on-premises CI/CD with a key file (ID 3), all the way to external hosting on a third-party platform (ID 7). An overview at the end shows you how to check and reset the respective authentication status.

Use Case 1: Node.js App on Cloud Run with Local Development [ID 1], [ID 4], [ID 6]

The scenario: A developer builds and deploys a Node.js/Express application on Cloud Run, connected to a Cloud SQL database. Throughout the development cycle, three methods of GCP authentication are used: a personal gcloud CLI user for the initial resource setup, Google Cloud ADC service account impersonation for local testing (to accurately mirror the production runtime identity), and a one-time service account impersonation for deployment—this ensures that the local ADC configuration remains completely untouched.

The people involved:

• Mark Sudo (Tech Lead)
  • Project Owner: Required to create service accounts (SAs), assign IAM roles, and retain full administrative control over the project.
  • Billing Account Administrator: Required to link the GCP project to a billing account (mandatory for paid services such as Cloud SQL or Cloud Run).
• John Doe (Developer)
  • Project Viewer: Allows them to browse resources in the Google Cloud Console and monitor project status.
  • Cloud Run Admin & Cloud SQL Admin: Required to create the Cloud Run services, as well as the Cloud SQL instance, databases, and users, during the initial setup.
  • SA Token Creator (for both SAs): Essential for service account impersonation during local testing, as it can generate short-lived credentials for the SAs.
  • Service Account User: Required to attach the App_SA to the Cloud Run service during setup so that the service runs under that identity.

The service accounts (SAs) used:

• App_SA (runtime identity for the Cloud Run app)
  • Cloud SQL Instance User: Required to log in to the database using IAM database authentication (instead of a static password).
  • Cloud SQL Client: Required for a secure connection to the Cloud SQL instance (e.g., via Cloud SQL Auth Proxy).
  • Logging Log Writer: Allows the application to write its logs directly to Google Cloud Logging.
• Deployment_SA (Identity for CI/CD Pipelines & Deployments)
  • Service Account User (restricted to App_SA): Required to deploy new Cloud Run revisions.
  • Cloud Build Editor & Artifact Registry Writer: To trigger Cloud Build jobs and push the finished Docker image to Artifact Registry.
  • Cloud Run Developer & Storage Object Admin: To deploy the new revision to Cloud Run and upload source code to the staging bucket.

An Overview of the Architecture:

• Front end: React + user management for to-do lists.
• Backend: Node.js/Express, hosted on Cloud Run + connection to a Cloud SQL database.
• Cloud Run: Is launched via the App_SA account. Cloud Run searches for the appropriate account via Google Cloud ADC and finds the App_SA and uses it.

Step-by-Step Procedure:

Step 1: Preparation

Mark Sudo creates the service accounts and assigns the necessary IAM roles to all accounts. He ensures a clear separation between users and service accounts. John Doe handles the administrative tasks; the App_SA runs the app, and the Deployment_SA handles the deployment.

Step 2: Setup

John Doe logs in and creates all the necessary resources using his personal user account.

gcloud auth login # All following gcloud commands will use John Doe's personal user [ID 1]
gcloud sql instances create ... # Create Cloud SQL instance, database etc.

Step 3: Local Testing

John Doe writes the Express app and sets up the connection to the Cloud SQL database. He then runs the app locally using service account impersonation. The idea behind this is that the developer’s local workstation should use exactly the same authentication as the production runtime environment. Since App_SA is used in Cloud Run, we also use it for local testing.

gcloud auth application-default login --impersonate-service-account=App_SA@myproject.com # SA Impersonation [ID 6]
node server.js # The code, or more precisely, the Google SDK will use the SA user.

Step 4: Deployment

John Doe wants to deploy the latest code to Cloud Run. To avoid overwriting his local ADC configuration (App_SA) from Step 3, he uses one-time impersonation for the deployment commands. This works perfectly because Group 1 (gcloud CLI commands) and Group 2 (Google Cloud ADC) are independent of each other. A –impersonate-service-account flag in a gcloud command does not affect the ADC configuration.
gcloud builds submit --impersonate-service-account=Deployment_SA@myproject.com ... # [ID 4]
gcloud run deploy --impersonate-service-account=Deployment_SA@myproject.com ... # [ID 4]

Use Case 2: Persistent Impersonation for Efficient Debugging [ID 2]

Scenario: A developer needs to run several gcloud CLI commands in succession as Deployment_SA to troubleshoot a failed deployment. Instead of appending the –impersonate-service-account flag to each individual command, they configure persistent impersonation in their active gcloud configuration.

# Enable impersonation persistently for the current gcloud configuration
gcloud config set auth/impersonate_service_account Deployment_SA@myproject.iam.gserviceaccount.com

# These commands will now automatically be executed as the Deployment_SA
gcloud builds list
gcloud run services list

# Disable impersonation to return to your personal user identity
gcloud config unset auth/impersonate_service_account

Use Case 3: On-Premises CI/CD with a Service Account Key File [ID 3]

Scenario: A local CI/CD pipeline (e.g., Jenkins) needs to run gcloud CLI commands to deploy an application to GCP. Since the system runs outside of Google Cloud, Workload Identity Federation cannot be used. As a last resort, a service account JSON key file is used.
Important security note: The use of static, long-lived JSON keys poses a security risk. This method of GCP authentication should truly only be used as a last resort if Workload Identity Federation cannot be set up.
# Authenticate gcloud using the securely mounted JSON key file
gcloud auth activate-service-account Deployment_SA@myproject.iam.gserviceaccount.com
--key-file=/secrets/deployment-key.json

# The pipeline can now run gcloud commands as the Deployment_SA
gcloud run deploy my-app --image=...

Use Case 4: Bootstrapping—Solving the Chicken-and-Egg Problem [ID 5]

Scenario: Before an automated CI/CD pipeline or a service account can take over, the initial infrastructure must be in place. Mark Sudo, the project owner, runs the very first Terraform scripts using his personal account. These scripts create the Deployment_SA and the App_SA and assign the first IAM roles.
# Mark logs in with his personal Project Owner account to create the local ADC file
gcloud auth application-default login
# Terraform uses Mark's permissions to create the first Service Accounts and Buckets
terraform apply
Why this approach? It’s the essential starting point. You use a human identity to “bootstrap” the machine identities (service accounts), which will later handle all automated tasks and deployments.

Use Case 5: Hosting on a Third-Party Platform [ID 7]

Scenario: John Doe deploys his Node.js backend on a platform outside of GCP (e.g., Render.com). The backend needs to connect to the Google Cloud SQL database or Cloud Storage. Since Render does not run on Google Cloud, the credentials cannot be automatically retrieved from the GCP metadata server.

Setup on Render.com:

1. Generate a JSON key for App_SA in the Google Cloud Console. (Reminder: Always handle static keys with the utmost caution.)
2. Use the “Secret Files” feature in the Render.com dashboard to securely store the contents of the JSON key. Render will then mount this file at a specific path, such as /etc/secrets/gcp-key.json.
3. Add the following environment variable to your Render Service settings: GOOGLE_APPLICATION_CREDENTIALS=/etc/secrets/gcp-key.json

Result: When the Node.js app starts on Render, the Google Cloud SDK (e.g., const { Storage } = require(‘@google-cloud/storage’);) automatically detects the GOOGLE_APPLICATION_CREDENTIALS environment variable, reads the JSON file, and securely authenticates the application as App_SA.

Overview: Check and Reset Authentication Status

When troubleshooting authentication issues or switching between identities, it’s helpful to know which identity is currently active. The following table shows how to check the current authentication status for each group and how to revoke or reset it.

Conclusion:

Proper GCP authentication is based on a few simple rules: Keep human logins separate from machine accounts, simulate production locally using impersonation, and avoid static key files whenever possible. This ensures that your cloud setup remains secure, organized, and flexible from the start.