IAM Roles, ACLs, Conditions and Deny Policies

What it is

Authorization decides what an authenticated principal may do on which resource. In Google Cloud an allow policy on a resource binds principals to roles, and roles are collections of permissions.

Two extra tools narrow access further: IAM conditions make a grant apply only in some situations, and deny policies block permissions no matter what is allowed.

How it works

Role types

Custom roles can be created at organization or project level, not on folders. You maintain them yourself, and new permissions Google adds to a service do not appear in them automatically.

Privileged roles and separation of duties

Some roles let the holder change who has access, which makes them as powerful as the access they can grant.

Separation of duties splits these so no single person can both make and approve a risky change. Classic splits: key administrators (Cloud KMS Admin) do not get CryptoKey Encrypter/Decrypter; people who create service accounts do not also deploy as them; network admins do not change IAM.

Least privilege at each level

Grant at the lowest level that covers the need: resource, then project, then folder, then organization. A grant on a folder applies to every project in it, including future ones.

Managing permissions through groups

Grant roles to Google groups, not to individual users. Joiners and leavers then change group membership, and the IAM policy stays readable and reviewable. Use separate groups per duty, such as gcp-prod-network-admins, rather than one broad admin group.

IAM and ACLs

Cloud Storage has two access systems. Uniform bucket-level access turns off object ACLs so only IAM applies; it is the recommended setting and is required for some features, such as IAM conditions on buckets.

Fine-grained access keeps ACLs on each object, which is harder to audit. Enforce uniform access with the organization policy storage.uniformBucketLevelAccess, and block public sharing with public access prevention.

IAM conditions

A condition is a CEL expression attached to a role binding. The grant applies only when it evaluates to true.

{
  "role": "roles/compute.instanceAdmin.v1",
  "members": ["group:contractors@example.com"],
  "condition": {
    "title": "until-end-of-project",
    "expression": "request.time < timestamp('2027-01-01T00:00:00Z')"
  }
}

IAM deny policies

A deny policy names principals and permissions that are refused, even if an allow policy grants them. It is attached to an organization, folder or project and inherited downward, and can list exception principals and a condition on tags.

{
  "displayName": "Only platform admins delete projects",
  "rules": [{
    "denyRule": {
      "deniedPrincipals": ["principalSet://goog/public:all"],
      "exceptionPrincipals": ["principalSet://goog/group/platform-admins@example.com"],
      "deniedPermissions": ["cloudresourcemanager.googleapis.com/projects.delete"]
    }
  }]
}

Managing deny policies needs the Deny Admin role (roles/iam.denyAdmin). Deny is the only way to take away a permission that a parent's allow policy grants.

A worked example

External auditors need read access to production for one quarter, and application teams who hold Owner on their projects keep deleting them by mistake. The engineer creates an auditor group and grants read-only predefined roles on the production folder with a request.time condition that ends with the quarter.

On the same folder, a deny policy like the one above blocks projects.delete for everyone except the platform admins group. Owner on a project no longer allows deletion, because deny is evaluated first.

How the exam asks about this

• "Grant a contractor access that expires automatically on a date." An IAM condition on request.time.
• "No one except one group may delete projects, even users with Owner on those projects." A deny policy with an exception principal set.
• "Stop object ACLs from granting access in any bucket." Enforce uniform bucket-level access with the storage.uniformBucketLevelAccess organization policy.