Defining access control at the organization, folder, project, and resource level using the principle of least privilege.

Defining Access Control at the Organization, Folder, Project, and Resource Level Using the Principle of Least Privilege

Design and Apply Custom IAM Roles with Precise Permissions

Custom IAM roles let you create a precise set of permissions that match exactly what a user needs to do their job, rather than giving them broad access that includes permissions they never use. Predefined roles come with many permissions bundled together, which can lead to over-permissioning and increased security risk if credentials are compromised. For instance, instead of granting the powerful Editor role to someone who only needs to start and stop virtual machines, you can create a custom role containing only compute.instances.start and compute.instances.stop.

Where you apply a custom role in the resource hierarchy matters because of policy inheritance, which means permissions granted at a parent level automatically flow down to all child resources. A role granting access to folder management should be applied at the folder level, not at the organization level where it would affect everything. If someone only needs to publish messages to one specific Pub/Sub topic, grant the Publisher role directly on that topic rather than at the project level.

To build effective custom roles, start by reviewing predefined roles to see if one already fits your needs before creating something new. Use tools like the Policy Simulator to test that your custom role provides the intended access without breaking existing workflows, and use the IAM Recommender to find opportunities to replace overly permissive roles with more granular ones. Avoid using basic roles like Owner, Editor, and Viewer in production because they include thousands of permissions.

When implementing custom roles, grant roles to Google Groups rather than individual users to simplify management, and ensure at least two principals have the Owner role on each project to prevent lockout. Use IAM Conditions to add context-based restrictions like time limits or IP address requirements. Regularly audit your IAM policies using the effective allow policy, which shows all permissions inherited from parent resources combined with directly attached policies, to ensure your custom roles are working as intended.

Map the Resource Hierarchy and Evaluate Policy Inheritance

The Google Cloud resource hierarchy has four levels that organize all cloud resources in a parent-child relationship. The organization node sits at the top and represents your entire company as the root of everything. Folders sit below the organization and can contain projects or other folders, letting you group resources by department or environment. Projects are the base containers that hold actual resources like virtual machines, storage buckets, and databases. Understanding this structure matters because access policies set at higher levels automatically apply to everything below them.

Allow policies inherit down the hierarchy in a predictable way. When you set a policy on the organization node, it automatically applies to all folders, projects, and resources beneath it. Similarly, policies set on a folder apply to everything inside that folder. The effective allow policy for any resource is the combination of policies directly attached to it plus all policies inherited from its ancestors. This means one policy at a high level can grant access across many resources.

Deny policies work differently because they are evaluated first and can block permissions even when allow policies would grant them. You can set deny policies at the organization, folder, or project level, and they also inherit down to child resources. This lets security teams establish broad restrictions at the top while keeping granular control at lower levels when needed.

Applying least privilege means thinking carefully about where in the hierarchy to grant roles. Giving someone the Network Admin role at the organization level provides enterprise-wide access, which makes sense for that role. For more restricted access, grant roles at the folder or project level to limit scope. If a user already has enough permissions through inheritance, adding redundant grants at lower levels adds confusion without providing additional access.

Moving resources within the hierarchy changes which policies apply because the resource loses permissions from its old parent and gains permissions from the new parent. This matters during organizational restructuring when projects move between folders. Folders can also create isolation boundaries between departments or environments, letting each business unit maintain its own security controls while staying under overall organizational governance.

Implement Conditional Access Controls and Context-Aware Policies

Google Cloud's resource hierarchy consists of organizations, folders, projects, and resources, with policy inheritance ensuring that permissions applied at parent nodes automatically propagate to child containers. The effective allow policy combines all inherited permissions with directly attached permissions, so security administrators must design access carefully to avoid granting more than intended. Deny policies can restrict inherited access across the hierarchy by blocking specific permissions before allow policies are evaluated.

IAM conditions use Common Expression Language to evaluate access requests dynamically, granting permissions only when specific attributes match defined criteria. These conditional role bindings narrow permissions beyond what standard role assignments provide. Administrators can configure conditions based on resource attributes like name prefixes, types, or services; resource tags that serve as key-value metadata; and contextual parameters such as date, time, or location. Access is granted only when all defined conditions are met.

When implementing delegated administration, administrators must restrict which roles secondary admins can assign by using IAM conditions with the iam.googleapis.com/modifiedGrantsByRole attribute. This limits a Project IAM Admin to granting only approved operational roles. Security architects should avoid assigning permissions that allow modified grants on roles containing setIamPolicy or custom roles the administrator manages, preventing privilege escalation.

The Organization Policy Service adds programmatic guardrails that define what operations and services are allowed across the hierarchy. Domain restricted sharing limits resource sharing to authorized corporate identities using managed or custom constraints. Attaching tags to resources enables conditional organization policy enforcement that changes configurations based on environment tier. Combining resource-level conditions with organization-wide constraints creates defense-in-depth access boundaries across all hierarchical levels.