Configuration, Auth & IAM

Authenticating, switching projects/configurations, and the IAM commands for service accounts and role bindings.

Authenticating#

Copy
gcloud auth login                                    # interactive browser login for a user account
gcloud auth login --no-launch-browser                 # for headless/remote shells
gcloud auth activate-service-account --key-file=key.json   # authenticate as a service account
gcloud auth list                                       # show all authenticated accounts + which is active
gcloud auth revoke my-account@example.com

Configurations — named sets of gcloud settings#

Copy
gcloud config configurations create staging           # a separate named config (project, account, region, etc.)
gcloud config configurations activate staging          # switch to it
gcloud config configurations list

A "configuration" in gcloud bundles project + account + default region/zone together — the equivalent of an AWS CLI named profile. Switching configurations is the standard way to work across multiple GCP projects/accounts from one terminal without re-typing --project on every command.

Setting individual config values#

Copy
gcloud config set project my-project-id
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
gcloud config list                                     # show current effective config

Projects#

Copy
gcloud projects list
gcloud projects describe my-project-id
gcloud projects add-iam-policy-binding my-project-id \
  --member="user:jane@example.com" --role="roles/viewer"

Service accounts#

Copy
gcloud iam service-accounts create my-service --display-name="My Service"
gcloud iam service-accounts list
gcloud iam service-accounts keys create key.json --iam-account=my-service@my-project-id.iam.gserviceaccount.com

A downloaded service-account key file is a long-lived credential — treat it like a password. For workloads running on GCP compute (GCE/GKE/Cloud Run), prefer attaching the service account directly to the resource instead of distributing key files, so there's no static secret to leak or rotate.

IAM role bindings#

Copy
gcloud iam service-accounts add-iam-policy-binding my-service@my-project-id.iam.gserviceaccount.com \
  --member="user:jane@example.com" --role="roles/iam.serviceAccountUser"
gcloud projects get-iam-policy my-project-id             # see the full policy, all bindings at once

add-iam-policy-binding is a read-modify-write under the hood — on a resource with many bindings, two concurrent add-iam-policy-binding calls can race and one can silently lose. For scripted/CI changes to a policy with many existing bindings, get-iam-policy + edit + set-iam-policy with an explicit etag is the safer pattern.