Cloud Resource Hierarchy and IAM

Granting permissions one resource at a time works briefly. As projects multiply, duplicated grants drift apart and nobody can easily explain why a user has access.

Google Cloud addresses this with a hierarchy and policies that can apply to an entire branch.

The Hierarchy

organization
└── folder
    └── project
        └── resource

Resources such as virtual machines and storage buckets belong to projects. Projects can be grouped into folders, and the organization node contains the managed hierarchy.

A project is more than a visual folder: it is a management boundary for resources, service activation, collaborators, and billing. Folders let administrators group projects around teams or environments and manage shared policy once.

IAM Is a Three-Part Statement

An access decision can be read as:

principal + role + resource scope

A principal is an identity, such as a person, group, or service account.
A role is a named collection of permissions.
The resource scope says where the grant applies.

A role granted at a higher level can affect descendants. This makes central policy efficient, but it also increases the impact of an overly broad grant. Deny policies can explicitly block permissions and are evaluated before applicable allows.

Choose the Narrowest Useful Role

Broad basic roles are easy to assign but often include unrelated permissions. Predefined roles describe a service-specific job. Custom roles can narrow permissions further, but their definitions must be maintained as services evolve.

Least privilege means granting the smallest practical role at the smallest practical scope. It does not mean creating a custom role for every person.

Workload Identities

Applications also need identities. A service account lets a workload receive roles without borrowing a person's credentials.

A service account has two sides:

It is a principal that can receive access to other resources.
It is itself a managed resource, so people need separate permission to view, administer, or impersonate it.

Keeping those sides separate avoids turning permission to configure an identity into unnoticed permission to act as that identity.

Design Check

Before adding a binding, ask: