Configuring access and security

IAM model

An IAM policy is a list of bindings, each binding a role (a set of permissions) to members (principals), optionally with a condition. A policy is attached to a resource (organization, folder, project or a specific resource such as a bucket) and inherited by all descendants. The effective access is the union of the policy on the resource and on every ancestor; you cannot revoke an inherited grant from below (use a deny policy or remove it at the level where it was granted).

A permission looks like compute.instances.start (service.resource.verb). You never grant permissions directly; you grant roles.

Viewing and editing policies

gcloud projects get-iam-policy my-proj --format=yaml
gcloud projects add-iam-policy-binding my-proj --member=group:devs@example.com --role=roles/compute.instanceAdmin.v1
gcloud projects remove-iam-policy-binding my-proj --member=group:devs@example.com --role=roles/compute.instanceAdmin.v1
gcloud projects set-iam-policy my-proj policy.yaml        # REPLACES the whole policy; edit from get output, keep the etag
gcloud organizations add-iam-policy-binding ORG_ID --member=... --role=...
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID --member=... --role=...
gcloud storage buckets add-iam-policy-binding gs://bucket --member=... --role=roles/storage.objectViewer
gcloud compute instances add-iam-policy-binding web-1 --zone=us-central1-a --member=... --role=roles/compute.osLogin

• add-iam-policy-binding and remove-... change one binding atomically; set-iam-policy overwrites the entire policy and can lock you out.
• The etag in a policy guards concurrent edits (read-modify-write).
• To find who has access or why: Policy Troubleshooter (explains if a principal has a permission on a resource), Policy Analyzer (who can access what) and IAM Recommender (removes unused permissions). gcloud asset analyze-iam-policy.
• Find which role has a permission and what a role contains: gcloud iam roles describe roles/storage.objectAdmin; gcloud iam list-testable-permissions.
• A principal can be granted a role at the resource level (most specific, least privilege) rather than the project; not every resource supports resource-level IAM.

Role types

Basic role traps: roles/viewer lets you read most things; roles/editor is too much for developers; the Owner role at the organization is exceptionally powerful. Primitive roles give access to all services in the scope, so a small mistake spreads widely.

Custom roles

gcloud iam roles create vmOperator --project=my-proj --title="VM Operator" \
    --description="Start and stop VMs" \
    --permissions=compute.instances.get,compute.instances.list,compute.instances.start,compute.instances.stop \
    --stage=GA
gcloud iam roles create fromFile --organization=ORG_ID --file=role.yaml
gcloud iam roles update vmOperator --project=my-proj --add-permissions=compute.instances.reset
gcloud iam roles update vmOperator --project=my-proj --remove-permissions=compute.instances.reset
gcloud iam roles describe vmOperator --project=my-proj
gcloud iam roles list --project=my-proj
gcloud iam roles delete vmOperator --project=my-proj      # soft delete, 7 days to undelete (then permanently gone after 37 days)
gcloud iam roles undelete vmOperator --project=my-proj

• Use a custom role when no predefined role fits the exact permissions (for example “start/stop VMs but not create or delete”).
• Custom roles don’t update automatically when Google adds new permissions to a service; you maintain them. A role has a launch stage (ALPHA, BETA, GA, DEPRECATED, DISABLED).
• Not every permission is supported in custom roles. Up to 3,000 permissions per role; 300 custom roles per org and 300 per project.
• Start from a predefined role: gcloud iam roles copy --source=roles/x --destination=myRole --dest-project=P.
• Common predefined roles to recognise: compute.admin, compute.instanceAdmin.v1, compute.networkAdmin, compute.securityAdmin, storage.admin, storage.objectAdmin, container.admin, container.developer, cloudsql.admin, cloudsql.client, bigquery.dataEditor, bigquery.jobUser, pubsub.publisher, pubsub.subscriber, logging.viewer, logging.logWriter, monitoring.viewer, iam.serviceAccountUser, iam.serviceAccountTokenCreator, iam.serviceAccountAdmin, resourcemanager.projectIamAdmin, billing.user.

Conditions, deny and boundaries

• IAM Conditions add attribute-based rules to a binding with CEL expressions: time of day or expiry (request.time < timestamp("2027-01-01T00:00:00Z")), resource name or type, or tags. Use for temporary access (just-in-time).

gcloud projects add-iam-policy-binding my-proj --member=user:ana@example.com --role=roles/compute.admin \
    --condition='expression=request.time < timestamp("2026-12-31T00:00:00Z"),title=temp-access'

• IAM deny policies block specific permissions for principals regardless of allow grants and are evaluated before allow. Created at org, folder or project.
• Principal access boundary policies limit which resources a principal can use.
• Privileged Access Manager (PAM) gives temporary, approved elevation.
• Organization policy (see the first domain) limits what can be configured; VPC Service Controls create a perimeter that stops data exfiltration from APIs even with valid IAM.

Best practices the exam rewards

• Least privilege: smallest role at the smallest scope.
• Groups over individual users; manage group membership in the directory.
• Predefined over basic; custom when needed.
• Separation of duties: for example, the person who manages IAM should not also administer the data.
• Service accounts per workload, not shared, with no keys.
• Review with Recommender and audit logs.
• Don’t use owner for automation; don’t grant roles/owner to service accounts.
• Allow IAM Admin roles sparingly (roles/resourcemanager.projectIamAdmin, roles/iam.securityAdmin): holding them lets a person grant themselves anything.

Service accounts

A service account (SA) is an identity for an application or VM, not a person. It is both a principal (given roles to access things) and a resource (others get roles on it to use or manage it).

gcloud iam service-accounts create app-sa --display-name="App SA"
gcloud iam service-accounts list
gcloud iam service-accounts describe app-sa@my-proj.iam.gserviceaccount.com
gcloud iam service-accounts disable|enable|delete app-sa@my-proj.iam.gserviceaccount.com
# Give the SA permissions (SA as a principal)
gcloud projects add-iam-policy-binding my-proj \
    --member=serviceAccount:app-sa@my-proj.iam.gserviceaccount.com --role=roles/storage.objectViewer
# Give someone permission on the SA (SA as a resource)
gcloud iam service-accounts add-iam-policy-binding app-sa@my-proj.iam.gserviceaccount.com \
    --member=user:ana@example.com --role=roles/iam.serviceAccountUser

Roles on a service account as a resource:

Common trap: to deploy a VM, Cloud Run service or function that runs as a service account, the deployer needs permission to create the resource and serviceAccountUser (actAs) on that SA. Without it deployment fails with a permission error on iam.serviceAccounts.actAs.

Assigning service accounts to resources

• Compute Engine: choose at creation (--service-account=... --scopes=cloud-platform), change while stopped (gcloud compute instances set-service-account). Processes on the VM get tokens from the metadata server (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token, header Metadata-Flavor: Google); client libraries use Application Default Credentials (ADC) automatically.
• Cloud Run / Cloud Run functions: --service-account=... at deploy.
• GKE: node service account per node pool, and Workload Identity Federation for GKE to map a Kubernetes service account to an IAM identity per Pod.
• Access scopes on VMs are a legacy filter on top of IAM. The effective access is the intersection of IAM roles and scopes; the easiest approach is cloud-platform scope and control access with IAM.
• A VM’s SA can be changed only while the VM is stopped; some services (Dataflow, Cloud Build) also take SA parameters.

Authentication options (strongest to weakest)

1. Attached service account (no credentials to manage): for code on Google Cloud.
2. Impersonation of an SA by a user or another SA for short-lived tokens.
3. Workload Identity Federation for workloads outside Google Cloud (AWS, Azure, GitHub Actions, OIDC/SAML).
4. Service account keys (JSON files): long-lived, risky; use only if nothing else works, rotate, and block creation with org policy iam.disableServiceAccountKeyCreation where possible.

gcloud iam service-accounts keys create key.json --iam-account=app-sa@my-proj.iam.gserviceaccount.com
gcloud iam service-accounts keys list --iam-account=app-sa@my-proj.iam.gserviceaccount.com
gcloud iam service-accounts keys delete KEY_ID --iam-account=...
gcloud auth activate-service-account --key-file=key.json
gcloud auth application-default login          # ADC for local development with your user

Keys are user-managed credentials with up to 10 per service account by default and no expiry unless you set an org policy to expire them.

Impersonation and short-lived credentials

Impersonation lets a principal act as a service account temporarily without a key, as long as it holds roles/iam.serviceAccountTokenCreator on that SA. The caller’s identity is recorded in audit logs.

# Run any gcloud command as the SA (no key, no activate)
gcloud storage ls gs://bucket --impersonate-service-account=app-sa@my-proj.iam.gserviceaccount.com
gcloud config set auth/impersonate_service_account app-sa@my-proj.iam.gserviceaccount.com
# Mint a short-lived access token (default 1 hour, up to 12 hours with org policy)
gcloud auth print-access-token --impersonate-service-account=app-sa@my-proj.iam.gserviceaccount.com
# ID token for calling a private Cloud Run service
gcloud auth print-identity-token --impersonate-service-account=... --audiences=https://api-xyz.a.run.app

• Delegation chain: SA A impersonates B which impersonates C when each holds TokenCreator on the next.
• Cloud Shell and workstation developers should impersonate instead of downloading keys.
• Service account usage can be checked with Policy Intelligence (service account insights show unused accounts and keys) and cleaned up.

Managing IAM of a service account

• Control who can use (serviceAccountUser), impersonate (TokenCreator) and administer (serviceAccountAdmin/keyAdmin) the SA; grant them on the SA itself, not the project, to limit blast radius.
• A project-level serviceAccountUser lets the holder act as every SA in the project; this is a classic privilege escalation path. Grant it on specific accounts.
• Deleting an SA breaks anything depending on it; it can be undeleted within 30 days (gcloud iam service-accounts undelete), and the disable action is a safer first step.
• Cross-project: SAs can be granted roles in other projects; check the org policy iam.disableCrossProjectServiceAccountUsage which controls attaching an SA from another project.

Other security controls