Resource Hierarchy and IAM Roles

Introduction to Resource Hierarchy and IAM

For a GCP Professional Cloud Security Engineer (PSE), the resource hierarchy is the skeleton upon which all security policies are hung. IAM (Identity and Access Management) is the nervous system that controls access. Understanding how they interact—especially regarding inheritance, overrides, and precedence—is fundamental to designing a secure and scalable cloud environment.

In this topic, we will move beyond basic "User/Role/Resource" concepts and dive into the complexities of large-scale organizational structures, the strategic use of Deny Policies, and the automation of the "Principle of Least Privilege" using Policy Intelligence.

白話文解釋（Plain English Explanation）

1. The Russian Nesting Dolls (Resource Hierarchy)

Imagine a set of dolls. The largest is the Organization. Inside it are Folders, inside folders are Projects, and inside projects are Resources (VMs, Buckets). If you paint a spot on the largest doll, every doll inside it is effectively "marked." This is IAM Inheritance. You cannot "un-paint" a spot on an inner doll if it was applied to the outer doll.

2. The Supreme Court (Deny Policies)

Think of standard IAM roles as local laws. They tell you what you can do. Deny Policies are like Constitutional Amendments or Supreme Court rulings. No matter what a local law (IAM Role) says, the Constitutional Amendment (Deny Policy) overrides it. If the Constitution says "No guns in schools," a local law granting "Gun access to all" is void in that specific context.

3. The Personal Trainer (IAM Recommender)

Imagine you have a key ring with 100 keys, but you only ever use 3. A personal trainer (the IAM Recommender) watches you for 90 days, notices you only use those 3 keys, and suggests you swap your massive key ring for a small one that only holds the 3 you actually need. This reduces your "security weight" (blast radius).

Organization, Folder, and Project Structure

The hierarchy is structured to allow for both centralized control and decentralized autonomy.

The Organization Node

The root of the hierarchy. It represents your company and is linked to a Cloud Identity or Google Workspace domain.

• Security Benefit: Allows for Organization Policy Constraints (e.g., "Disable external IP addresses for all VMs").

Folders

Used to group projects based on departments (e.g., "Finance", "Engineering") or environments (e.g., "Prod", "Dev").

• Nesting: Folders can be nested up to 10 levels deep.

Projects

The base unit for enabling services and billing. Every resource must belong to a project.

Inherited vs. Direct IAM Bindings

The Additive Nature of IAM

IAM policies are additive. A user's effective permissions are the union of the permissions granted at the Org, Folder, Project, and Resource levels.

Inheritance Flow

• Direct Binding: Granting roles/storage.admin on a specific bucket.
• Inherited Binding: Granting roles/storage.admin at the Project level, which automatically applies to every bucket in that project.

Primitive, Predefined, and Custom Roles

Primitive Roles (The "Big Three")

• Owner, Editor, Viewer.
• PSE Warning: Avoid these in production. They are too broad and violate the Principle of Least Privilege.

Predefined Roles

Created and maintained by Google. They provide granular access to specific service actions (e.g., roles/compute.instanceAdmin).

• Benefit: Automatically updated by Google when new permissions are added to a service.

Custom Roles

Created by the user to bundle specific permissions.

• Use Case: When no predefined role fits a highly specific job function.
• Maintenance: You must manually update custom roles if the underlying service introduces new required permissions.

IAM Recommender for Least Privilege

The IAM Recommender is part of the Policy Intelligence suite. It uses machine learning to analyze access patterns.

• Lookback Period: Analyzes the last 90 days of activity.
• Suggestions: If a user has roles/editor but only uses storage permissions, it recommends switching to roles/storage.objectAdmin.

Deny Policies and Their Precedence

Introduced to provide an explicit "No" in the additive IAM world.

• Precedence: Deny policies are evaluated before allow policies. If a Deny policy matches, access is blocked regardless of any Allow policies.
• Scope: Can be applied at the Org, Folder, or Project level.
• Exception: You cannot deny access to the "Owner" of a project from managing the project itself (to prevent lockouts), but you can deny them access to data within the project.

Resource-Level IAM

Some services allow IAM policies to be attached directly to individual resources, providing the highest level of granularity.

• Cloud Storage: IAM on individual buckets.
• BigQuery: IAM on individual datasets or even tables/views.
• KMS: IAM on individual encryption keys.

Managing Policy Inheritance and Overrides

Hierarchical Safeguards

1. Organization Policies: Set constraints that cannot be overridden by IAM (e.g., "Restrict VPC Peering").
2. Resource Manager Liens: Prevent projects or resources from being accidentally deleted.

IAM Policy Troubleshooting and Audit

Cloud Audit Logs

• Admin Activity: Logs all metadata changes (who changed the IAM policy).
• Data Access: Logs who accessed the data (must be explicitly enabled for most services).

Policy Troubleshooter

A tool that answers: "Why does this user have/not have this permission?" It analyzes the entire hierarchy and Deny policies.

Role-Based Access Control (RBAC) Design

Best Practices for RBAC

1. Job-Function Centric: Create groups based on job roles (e.g., "Network-Admins", "DB-Admins").
2. Avoid Individual Assignments: Always bind roles to groups.
3. Naming Convention: Use clear names like [email protected].

Best Practices for Custom Role Creation

• Don't Over-engineer: Check if a combination of predefined roles works first.
• Permission Mapping: Use the gcloud iam roles copy command to start from a predefined role and strip away what you don't need.
• Naming: Include the project ID in the custom role ID to avoid conflicts.

CLI Commands for Hierarchy and IAM

Viewing Project Policy

gcloud projects get-iam-policy PROJECT_ID

Adding a Binding at the Folder Level

gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
    --member="group:[email protected]" \
    --role="roles/resourcemanager.folderAdmin"

Creating a Custom Role

gcloud iam roles create myCustomRole --project=my-project \
    --file=role-definition.yaml

Security Best Practices for PSE

1. Audit Monthly: Use the Policy Analyzer to find "ghost" permissions.
2. Use Folders for Environment Isolation: Don't mix Prod and Dev projects in the same folder if they require different security guardrails.
3. Limit 'Owner' Role: Use roles/resourcemanager.projectIamAdmin instead of roles/owner for people who only need to manage permissions.

Troubleshooting Scenarios

Scenario: User has 'Storage Admin' but can't delete a bucket.

Diagnosis: There might be a Deny Policy at the Folder or Org level explicitly forbidding storage.buckets.delete. Fix: Check the Deny policies using gcloud iam deny-policies list.

Scenario: A Custom Role is missing permissions for a new feature.

Diagnosis: Custom roles do not automatically inherit new permissions added by Google. Fix: Manually identify the new permission (e.g., via the API documentation) and add it to the custom role definition.

PSE Exam Scenarios

Scenario 1: Least Privilege Automation

"A security auditor wants to ensure that all developers have the minimum permissions required without manual review. What should you use?" Answer: Implement the IAM Recommender and automate the application of its suggestions using a Cloud Function or a third-party tool.

Scenario 2: Preventing Data Exfiltration

"How can you ensure that no one, including Project Owners, can make a GCS bucket public?" Answer: Apply an Organization Policy Constraint (storage.publicAccessPrevention) at the Organization level.

FAQ

Q1: Can I move a project between Folders? A1: Yes, using the gcloud projects move command. Note that the project will lose inherited permissions from the old folder and gain them from the new one.

Q2: What is the maximum depth of the folder hierarchy? A2: 10 levels.

Q3: Do Deny Policies affect Service Accounts? A3: Yes. Deny policies apply to all principals, including users, groups, and service accounts.

Summary Checklist

• Diagram a standard enterprise resource hierarchy.
• Explain the difference between additive IAM and Deny policies.
• List the limitations of Custom Roles (Folder/Org level restriction).
• Describe how the IAM Recommender calculates its suggestions.
• Understand how Organization Policies differ from IAM.