Verified7 commandsAI-assisted

Configuration, Auth & IAM

Verified against Google Cloud SDK 553.0.0, flags verified via `gcloud <cmd> --help`, 2026-08-21 · official docs

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

Authenticating#

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#

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#

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#

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#

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#

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.

IAM conditional bindings#

gcloud projects add-iam-policy-binding my-project-id \
  --member="user:jane@example.com" --role="roles/storage.objectViewer" \
  --condition='expression=request.time < timestamp("2027-01-01T00:00:00Z"),title=expires-2026,description=Temporary access, expires end of 2026'

gcloud projects add-iam-policy-binding my-project-id \
  --member="user:jane@example.com" --role="roles/viewer" --condition=None   # explicitly add a binding with no condition

A conditional binding only grants the role while the CEL expression evaluates true — commonly used for time-boxed access grants like the one above. --role cannot be a basic role (roles/owner, roles/editor, roles/viewer) when a real condition is attached; title and expression are required, description is optional. --condition-from-file takes the same fields from a JSON/YAML file instead of an inline key-value string, which is easier to keep readable for a long CEL expression.

Next →Compute: GCE & GKE