Members & Policies

Exam guide§4.1

A member (or principal) is the "who" - the identity a role is bound to. This page covers the five member types and the policies that bind them to roles on a resource. (The high-level "who can do what" framing is in the section intro.)

A policy binds member identities (the "who", red) to roles (the "what", green). The five role names are just examples - any predefined or custom role works.

Members

Five member types. The first four are identities; the last two are special values that open access wide.

Google Account - a person: userid@gmail.com or any domain email tied to a Google Account.
Service account - belongs to an application/workload, not a person (…@…gserviceaccount.com). Details: Service accounts.
Google group - a named collection of accounts + service accounts with one email; grant or change access for the whole group at once instead of user-by-user.
Workspace / Cloud Identity domain - every account in your org's domain (example.com). Workspace bundles Gmail/Docs/Drive; Cloud Identity gives the same user/group management without the collaboration apps.
allAuthenticatedUsers / allUsers - any authenticated Google identity, or literally anyone on the internet (see the gotcha below).

IAM only binds existing identities to roles - you cannot use it to create or manage users and groups. Those live in Cloud Identity or Google Workspace. (Getting on-prem identities in: Cloud Identity.)

user:alice@example.com - individual Google account
group:admins@example.com - Google group (preferred - see best practices)
serviceAccount:sa@proj.iam.gserviceaccount.com - service account
domain:example.com - everyone in a Workspace/Cloud Identity domain
allAuthenticatedUsers - any Google account or SA (still authenticated)
allUsers - literally anyone on the internet, no auth

Policies

A policy binds members to roles on a resource. IAM has four kinds, evaluated together: allow policies grant, deny policies block, conditions gate a grant on context, and organization policies restrict configuration across a subtree.

Allow policies

An allow policy (the plain "IAM policy") is what grants access. It's attached to a resource, controls that resource and its descendants, and each of its bindings ties one or more principals to a single role. A policy is just a bindings array plus an etag (for safe read-modify-write) and version:

{
  "bindings": [
    {
      "members": ["user:jie@example.com"],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": ["user:raha@example.com", "user:jie@example.com"],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Here Jie is in both bindings (Organization Admin and Project Creator) while Raha is only a Project Creator - so the same policy grants Jie strictly more than Raha. Access is additive: a principal gets the union of every binding they appear in.

A resource's effective allow policy is the union of its own bindings and every binding inherited from above - there is no "deny by omission" at a lower level. The policy hierarchy always tracks the resource hierarchy: move a project into a different organization and its IAM policy immediately re-inherits from the new org. (How inheritance flows down and why a child can't revoke a parent's grant is in Resource hierarchy.)

IAM evaluates a resource against its own policy bindings PLUS every binding inherited from its ancestors. A Pub/Sub topic’s effective policy = the project’s inherited binding + the topic’s own bindings, and the inherited ones cannot be taken away lower down.

allUsersPublic, no credentials at all - the classic cause of exposed buckets.

allAuthenticatedUsersRequires a valid Google login, but is NOT restricted to your org - random Gmail users count.

Neither is "your company only".

Deny policies

A deny policy blocks permissions no matter what roles a principal holds, and IAM checks deny rules before allow policies - so a deny always wins over a grant. A deny policy is a set of deny rules; each rule specifies:

the principals who are denied,
the permissions they can't use, and
optionally, a condition that must be true for the denial to apply.

Once denied a permission, a principal can't do anything that requires it - even if a role grants it.

IAM Conditions

IAM Conditions add attribute-based access control: the role in a binding is granted only when a condition expression evaluates to true. The expression is a set of logic statements over request/resource attributes (time, resource name, request IP, …). Typical uses: temporary access during a production incident, or limiting access to requests coming from the corporate network. Conditions live in the role bindings of the resource's IAM policy.

IAM Conditions are supported only on predefined / custom roles, and only for resource types that accept them - never on basic roles (owner/editor/viewer).

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer" \
  --condition='title=temp-access,expression=request.time < timestamp("2026-07-01T00:00:00Z")'

Organization policies

An organization policy is a configuration of restrictions applied to the organization node, a folder, or a project. Where an IAM allow policy grants, an org policy restricts - it caps what anyone (even an Owner) can do across a whole subtree.

Defined by a constraint (e.g. constraints/iam.disableServiceAccountKeyCreation) set to the desired restriction.
Applied at org / folder / project; inherited by all descendants.
Exceptions can be made only by a user with the Organization Policy Administrator role.
Independent of IAM roles - a guardrail layered on top of them, not a grant.

Both block, differently.

IAM deny policyDenies specific principals specific permissions (checked before allow policies). Use for principal-specific blocks.

Organization policyRestricts configurations across a resource subtree regardless of who is acting (e.g. "no external IPs", "no SA key creation"). Use for org-wide guardrails.

Recap

# Who has what on a project
gcloud projects get-iam-policy PROJECT_ID
 
# Add one binding (simplest form)
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/viewer"
 
# Remove a binding
gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/viewer"

DECISIONWhich member type do I bind?

A team of people→group:

One human (rare)→user:

An app / VM / workload→serviceAccount:

Public read (e.g. static site)→allUsers (deliberately)

Members​

Policies​

Allow policies​

Deny policies​

IAM Conditions​

Organization policies​

Recap​