Google Cloud / Basic: Resource and Access Boundaries / Lesson 3

IAM and Effective Authorization

Reason about principal, permission, resource, and context instead of treating one role name as proof of access.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish principal, role, permission, and policy binding.
Explain inheritance, conditions, and deny interaction.
Review broad grants without claiming to evaluate real access offline.

Authorization asks who may do what on which resource

Authentication identifies a principal; IAM authorization determines whether the requested operation is permitted. A principal can be a human, group, service account, or federated identity. A role bundles permissions, and a binding associates principals with a role at a resource scope. Knowing the active login alone does not tell you the effective permissions of a workload.

Start with the exact failing or required permission and target resource. A friendly role name may include more or fewer permissions than expected and can evolve for predefined roles. Review official role definitions and the smallest useful scope. Avoid basic broad roles as a shortcut when a task-specific predefined or maintained custom role fits.

Read a binding without applying it

The illustrative JSON gives a synthetic group an object-viewing role in a policy’s eventual attachment scope. The snippet is not sent to any API and is not a complete claim about effective access. Policy versioning, conditions, concurrency tokens, and service-specific requirements need the actual interface contract. Editing a local JSON file grants nothing.

A role on a project can affect resources below it under the documented hierarchy. Placing the same binding on a narrower supported resource can reduce scope. Decide the intended boundary before changing policy. Members of a group can change over time, so group ownership and review are part of access governance.

json Illustrative allow-policy binding

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["group:readers@example.invalid"]
    }
  ]
}

This non-runnable document describes a binding shape; no policy is created or validated against a cloud resource.

Effective policy includes more than local allow grants

Inherited allow grants, applicable deny policies, conditions, principal restrictions, and service controls can all matter. A local allow-policy listing is therefore not a complete authorization decision. Conditions depend on supported attributes and request context; a text that looks like a condition is not automatically valid for every service. Deny support also has documented permission and resource scope.

Separate an IAM denial from organization-policy rejection, disabled API, missing service configuration, or network failure. They can produce similar user-visible inability while requiring different evidence. Broadening permissions without diagnosis can add risk and leave the original failure unchanged.

Local review can flag scope without proving enforcement

The offline Python example finds a basic owner role in invented bindings. It flags a review item; it does not declare the real policy insecure or decide access. A broad role can be intentional under an exceptional controlled process, but the justification, scope, expiry, and reviewer should be explicit. Least privilege is a maintained relationship between required work and granted authority.

Do not hard-code a small permission dictionary and call it a Google IAM simulator. Roles and evaluation rules are service-maintained. Local tests are useful for a team’s declared policy conventions, such as requiring an owner for every exception, while live enforcement needs authorized inspection and service-aware tools.

python Flag a synthetic broad-role review item

bindings = [{"role": "roles/viewer", "members": ["group:readers@example.invalid"]}, {"role": "roles/owner", "members": ["group:exception@example.invalid"]}]
review = [binding["role"] for binding in bindings if binding["role"] in {"roles/owner", "roles/editor"}]
print("broad-role review", ",".join(review))

Expected output

broad-role review roles/owner

The local convention flags roles/owner; it does not calculate any real principal’s permissions.

Access changes need identity and rollback context

Record who requested a grant, the workload or human identity, exact resource scope, required operations, reviewer, and removal trigger. Separate administrative role changes from data access. Time-bound access and impersonation can support controlled operations, but they must use supported policies and approval processes rather than a shared credential file.

Test design examples against expected allowed and forbidden cases conceptually, and document what a real policy test would still require. Never resolve a permission problem by publishing credentials or granting public access. This course performs no access changes; the review record is the learning artifact.

Common errors and fixes

A successful login is treated as authorization.

Why it happens: Identity and permissions are conflated.
How to fix it: Identify the workload principal and required permission on the exact resource.
Prevent it next time: Keep authentication and authorization evidence separate.

A project grant appears to have no effect.

Why it happens: Another control, context, or target may be responsible.
How to fix it: Diagnose the exact failure and applicable policies before adding roles.
Prevent it next time: Record resource names and request context.

An offline role list is called an effective-access test.

Why it happens: A partial model omits real evaluation rules.
How to fix it: Label it as a local convention check.
Prevent it next time: Use official service-aware evidence for actual enforcement.

Check your understanding

1. A user can view a bucket’s metadata but cannot read an object. What should be investigated before granting Owner?

Show worked solution

Determine the exact principal, bucket/object resource, denied permission, policy inheritance, conditions, and any relevant service controls. Metadata and object operations can require different permissions. Confirm that the application uses the expected credentials. A broad grant may mask the distinction and still fail if another policy layer blocks the request.

2. Why is a group binding not a complete record of which humans have access over time?