IAM Roles and Organization Policy Enforcement

Design and Apply IAM Roles for Principle of Least Privilege means every identity gets only the permissions and scope needed for its job. In Google Cloud, Identity and Access Management (IAM) (opens in a new tab) enforces this with allow policies that bind principals to roles on a node in the resource hierarchy, so access flows from the principal through the role to the organization, folder, or project and then to its children. Predefined roles are the starting point, custom roles tighten them, and hierarchy placement, groups, conditions, and guardrails limit their reach.

1.1IAM Allow Policies Bind Principals to Roles on Resources

The IAM access model binds principals, roles, permissions, and allow policies into one authorization decision. A principal is the identity that requests access, such as a Google Account for a user, a service account for workloads and automation, a Google Group, or a Google Workspace or Cloud Identity domain. A role is a collection of permissions, a permission determines which operation is allowed on which resource, and an IAM allow policy binds a set of principals to a role on a specific resource. When a principal is granted a role, the principal receives all permissions in that role but cannot perform any action that was not granted.

An allow policy attaches to a resource node and inherits to that node and all of its children unless further constrained. If no resource conditions are specified, the grant confers blanket permissions on all child resources under the attachment point. Cloud Identity (opens in a new tab) is the separate identity service that centrally manages users and groups and enables single sign-on, so IAM policies reference managed identities rather than unmanaged consumer accounts that bypass joiner-mover-leaver controls.

1.2Predefined, Custom, and Basic Role Classes

Predefined, custom, and basic roles differ in precision, and least privilege depends on choosing the narrowest role that still allows the work. Predefined roles are maintained by Google for job functions and products, such as Storage Admin (roles/storage.admin), Organization Policy Administrator (roles/orgpolicy.policyAdmin), Project Creator (roles/resourcemanager.projectCreator), Billing Account User (roles/billing.user), and Project Billing Manager (roles/billing.projectManager). Custom roles are customer-defined collections of permissions, often cloned from a predefined role and then reduced to remove unneeded operations. Basic roles such as Owner and Editor are broad legacy grants, and Editor (roles/editor) grants such wide project control that compromise of one workload can lead to control of the entire project.

Start with the predefined job-function role, then create a custom role only when the predefined set is still too broad or mixes duties that must be separated.

1.3Placing Grants at Organization, Folder, and Project Levels

The Organization resource (opens in a new tab) is the apex of the hierarchy and provides central visibility and control over every resource that belongs to it. An organization contains folders, a folder groups related projects, and a project contains service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints. A parent folder can contain up to 300 folders and folders can nest up to 10 levels deep, which allows tenants to be arranged into nested hierarchies when scale requires it.

Grants inherit downward, so an organization-level grant applies to all folders and projects, a folder grant applies to all projects under that folder, and a project grant applies only inside that project. Least privilege therefore places each grant at the lowest node that covers the work: organization grants only for central administrators, folder grants for team or environment administration, and project grants for workload operators. Projects are the primary isolation boundary because IAM configuration, workload segregation, and resource quotas are enforced per project, so placing different environments or clusters in different projects prevents a misconfiguration, compromise, or quota exhaustion in one project from affecting the others.

Use Google Groups (opens in a new tab) to assign roles to teams rather than to individual users, then bind each group to the appropriate role at the appropriate node. For example, a Network Team folder can hold per-environment projects for virtual private clouds, a Cluster Team folder can hold per-environment folders that group production or staging cluster projects for shared policy and log sinks, and a Tenants folder can hold per-tenant subfolders and projects. To grant an organization-level role, the administrator opens IAM & Admin for the organization, identifies existing principals and their roles, adds a new principal by identifier, selects each required role, and saves the binding so the policy attaches to the organization resource.

1.4Hardening Service Accounts and Automation Identities

Service accounts and pipeline identities require the same least-privilege discipline as users because automation often holds standing access to production. Default service accounts are automatically created by Google Cloud services, and without controls they are automatically granted the Editor role on the project. The boolean organization-policy constraint constraints/iam.automaticIamGrantsForDefaultServiceAccounts set to False disables those automatic broad grants and forces deliberate assignment of only minimal permissions.

External keys and standing credentials expand that risk, so the constraint constraints/iam.disableServiceAccountKeyCreation set to True blocks creation of user-managed keys in affected projects and constraints/iam.disableServiceAccountKeyUpload blocks upload of external public keys. If keys must exist, the constraint constraints/iam.serviceAccountKeyExpiryHours with value 2160 enforces rotation at least every 90 days, and Workload Identity Federation (opens in a new tab) lets CI/CD systems and external workloads authenticate without long-lived service account keys. New organizations also grant Project Creator and Billing Account Creator to the entire domain by default, so production governance removes those domain-wide bindings and replaces free-form creation with a controlled project-creation and billing-association process.

1.5Narrowing Grants with Conditions, Deny Policies, and Access Boundaries

Conditions and guardrails narrow an otherwise broad role binding without creating a new role for every exception. IAM Conditions and tags allow or deny a policy based on attributes such as a resource tag, so the same role grants different effective access on tagged versus untagged resources across the hierarchy. IAM deny policies constrain which permissions can actually be exercised or granted, including limiting which principals a deployment pipeline may grant access to. Principal access boundary (PAB) policies (iam.googleapis.com/PrincipalAccessBoundaryPolicy) set an organization-level upper bound on what a principal can access, which reduces the reach of a compromised identity and helps contain phishing and data exfiltration.

Deployment pipelines deserve explicit limits because their service account can otherwise escalate its own access. Whenever possible, the pipeline service account receives roles without any *.setIamPolicy permission and never receives Editor or Owner. When policy management is unavoidable, first grant *.setIamPolicy only on specific resources rather than the whole project, then use deny policies to constrain grantable permissions and principals, and then use IAM Conditions to restrict which roles the pipeline may grant to roles that themselves lack *.setIamPolicy. Domain restricted sharing constraints iam.allowedPolicyMemberDomains and iam.managed.allowedPolicyMembers further enforce least privilege by defining which Cloud Identity or Google Workspace customer IDs may appear in allow policies, which prevents grants to unmanaged external accounts. High-risk grants such as Organization Admin and Super Admin are monitored through Cloud Audit Logs with alerts, and offboarding processes deactivate accounts and reset permissions so stale bindings do not accumulate.

Implement and Manage Organization-Level Policy Constraints means using central guardrails to control how resources can be configured across the hierarchy. The Organization Policy Service (opens in a new tab) provides centralized, programmatic control by letting an organization policy administrator define an organization policy, which is a set of restrictions called constraints that apply to a resource node and its descendants. A policy enforced at the Organization resource flows to folders and projects below it, so compliance rules for regions, services, identities, and network protocols apply consistently without configuring each project individually.

2.1How Organization Policy Service Enforces Guardrails

The Organization Policy Service evaluates every relevant create or update request against the policy attached to the target hierarchy node. An organization policy can be enforced at the organization, folder, or project level, and the Resource Manager hierarchy determines which policies affect a given workload. This design separates ownership: central administrators own the guardrails at the organization or folder, while project teams own workload resources inside those boundaries. Because enforcement happens at request time, a non-compliant request fails and returns an error to the caller instead of creating a misconfigured resource.

2.2Managed Constraints Versus Custom Constraints

Managed constraints are built-in restrictions supplied by the Organization Policy Service, while custom constraints restrict specific resource fields for finer control. Managed constraints cover broad guardrails such as allowed regions, allowed services, allowed IAM members, TLS versions, and service account key behavior. Custom constraints extend the same enforcement model to service-specific resources, such as Vertex AI endpoints or Workload Identity Federation pools, where an organization needs to allow or deny particular field values. Choose a managed constraint when a built-in guardrail meets the requirement, and choose a custom constraint when compliance depends on a field that no managed constraint addresses.

Custom constraints are defined and managed through organization policy tooling for services that expose constrainable fields. For example, custom organization policies (opens in a new tab) can target Gemini Enterprise or Cloud Domains resources where field-level allow or deny values are required. This keeps the enforcement model consistent: the same hierarchy attachment, inheritance, and request-time evaluation apply whether the constraint is managed or custom.

2.3Inheritance, Override, and Non-Retroactive Enforcement

Policy inheritance means an organization policy enforced on a parent is automatically enforced on all of its children. If a policy is enforced on a folder, Google Cloud enforces the policy on all projects in that folder, and a policy on the organization reaches every folder and project beneath it. A child can override inherited policy by setting its own organization policy on the child resource, and that child policy then flows to its own descendants. This order matters for operations: set strict defaults high in the hierarchy first, then apply narrower exceptions lower only after confirming the business need, because a loose child policy can weaken a central guardrail.

Policy changes do not remediate existing resources retroactively. A new policy does not change existing resource configurations, and an existing configuration remains valid even if it would violate the new rule. The policy blocks only future transitions from a compliant value to a non-compliant value, so teams must separately audit and fix resources that already exist.

2.4Location, Service, and Identity Guardrails

Location, service, and identity constraints establish where data can live, which services can be used, and which identities can receive access. The Resource Location Restriction (gcp.resourceLocations) constraint limits resource creation and data storage to an approved list of Google Cloud regions, which supports data residency and regulations such as HIPAA and GDPR. The service usage constraint (gcp.restrictServiceUsage) creates an allowlist of approved services per folder or project, so a sensitive production folder can permit only a small set of data-storing services while a sandbox folder permits a larger set. Domain restricted sharing (iam.allowedPolicyMemberDomains) and its managed variant (iam.managed.allowedPolicyMembers) limit which Cloud Identity or Google Workspace customer IDs can be added to Identity and Access Management (IAM) allow policies, which prevents grants to external accounts that do not follow corporate multifactor authentication and password rules.

The table shows a core tradeoff: allowlists for locations, services, and identities default to deny and require explicit approval, while the TLS constraint defaults to allow and requires explicit denial. Geography adds another dependency because Google Cloud services differ in regionality, so an allowed-region list must account for multiregional resources and where data is stored versus processed.

2.5Service Account and Network Protocol Hardening

Service account and protocol constraints reduce privilege and encryption risk from default behaviors. The boolean constraint constraints/iam.automaticIamGrantsForDefaultServiceAccounts, when set to False, stops Google Cloud from automatically granting the Editor role (roles/editor) to newly created default service accounts, which forces teams to grant only minimal necessary permissions. The boolean constraint iam.disableServiceAccountKeyCreation, when set to True, blocks creation of user-managed service account keys in affected projects, which removes unmanaged long-term credentials, while iam.disableServiceAccountKeyUpload blocks uploading external public keys to service accounts. Together these constraints move authentication from persistent keys toward short-lived, deliberately granted access, so compromise of one workload has less ability to spread across a project.

The Restrict TLS Versions (gcp.restrictTLSVersion) constraint hardens data in transit by denying handshake requests from clients that use older protocol versions. The constraint uses a deny list, which denies explicit values and allows all others, and an error occurs if an allow list is attempted. To allow only TLS 1.3, the organization sets ["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"] at the organization level. Due to hierarchy evaluation, that denial applies to the specified node and all descendant folders and projects unless a child defines its own policy to change the inheritance.

2.6Using Tags for Conditional Enforcement

Tags are annotations on resources that enable conditional allow or deny decisions beyond hierarchy position alone. A tag attaches to a resource, and an IAM or organization policy condition checks whether that tag is present before allowing the operation. This lets central teams keep a broad hierarchy policy while carving precise exceptions, such as different controls for production versus development resources that live under the same folder. Use tags when hierarchy alone is too coarse, because tags add fine-grained control across the resource hierarchy without creating extra folders or projects solely for policy boundaries. Enterprise multi-tenancy patterns (opens in a new tab) use this same idea to share a folder hierarchy while isolating tenants and environments by project and tag.

Analyze and Troubleshoot Effective IAM Policies and Policy Inheritance means evaluating the combined result of every policy attached along the resource path. Identity and Access Management (IAM) (opens in a new tab) allow policies grant access, while deny policies, principal access boundary (PAB) policies, IAM Conditions with tags, and Organization Policy Service constraints limit what those grants can actually do. Troubleshooting means walking that same path to find which level granted access and which boundary removed it.

3.1Hierarchy Path That Carries IAM and Organization Policy Inheritance

The Google Cloud resource hierarchy is the inheritance path for both IAM and organization policies. The Organization resource (opens in a new tab) is the apex of the hierarchy and provides central visibility and control over every resource that belongs to the organization. An organization can contain one or more folders, each folder can contain one or more projects, and projects contain service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints.

Policies attached higher in that tree flow downward to children. Folders allow different teams to set policies that cascade across multiple projects, while projects segregate environments and teams from each other. A parent folder can contain up to 300 folders and folders can be nested up to 10 levels deep, so a single high-level grant can reach a very large set of descendant projects and resources.

3.2IAM Principals, Roles, Permissions, and Allow Policies

An IAM decision always involves the same four concepts working together. A principal authenticates with an identity that Google Cloud understands, a role collects permissions, and an allow policy attached to a resource binds principals to that role.

• Principal: a Google Account, service account, Google Group, or Google Workspace or Cloud Identity account that can access a resource. A principal cannot perform any action that it is not permitted to do.
• Role: a collection of permissions, such as job-function predefined roles or custom roles derived from them.
• Permission: determines what operation is allowed on a resource, including RESOURCE_TYPE.setIamPolicy, which allows changing the allow policy itself. When a principal is granted a role, it receives all permissions that the role contains.
• IAM allow policy: binds a set of principals to a role on a specific resource. When access is needed, a policy is created and attached to the organization, folder, project, or service resource.

Access is evaluated at request time against the policies attached to the target resource, not only at sign-in. Those policies can include one or more allow policies, zero or more deny policies, and zero or more principal access boundary policies. Workforce principals use identifiers such as principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT, and group-based access can use principal sets filtered by attributes.

3.3How Direct and Inherited Grants Combine into Effective Access

Effective access for a principal on a resource reflects directly applied policies plus every inherited policy from its parent folder chain and organization. A grant at the organization or folder level therefore reaches all descendant projects unless a separate boundary blocks it, which is why folder design is also access design. The enterprise example uses top-level folders for the Network Team, Cluster Team, and Tenants, with per-environment projects or per-environment folders so one policy can cover all development, staging, or production projects at once.

Direct attachment narrows or widens that inherited baseline. IAM is per-project for many configurations, so placing different clusters in different projects ensures that a misconfiguration in one project does not affect all clusters at once and limits blast radius from a compromised workload. If no resource conditions are specified for a role, the role has blanket permissions on all child resources, while tags and IAM Conditions add fine-grained control by conditionally allowing or denying access based on whether a resource has a specific tag.

3.4Organization Policies, Deny Policies, and Boundaries That Limit Grants

Organization policies do not grant IAM permissions; they constrain configuration and behavior across the hierarchy through the Organization Policy Service. The Restrict TLS Versions (gcp.restrictTLSVersion) constraint shows how hierarchy evaluation works: it uses a deny list, denies explicit values such as TLS_VERSION_1 and TLS_VERSION_1.1, and allows all others. A restriction set on the organization applies to that node and all of its folders and projects, but it can be overridden on a child by setting a separate organization policy on that folder, and that child policy then applies to each of its own children.

The same inheritance pattern applies to identity guardrails that troubleshooters must check when an allow appears correct but the action still fails:

Default organization-wide grants are another common source of excess effective access. New organizations grant Project Creator (roles/resourcemanager.projectCreator) and Billing Account Creator to all managed identities in the domain, which allows free-form project creation outside governance conventions. Removing those domain-wide bindings and replacing them with a request-based project creation process keeps inheritance clean.

3.5Diagnosing Unexpected Allows and Denials

Diagnosing an IAM issue means reconstructing the full set of policies that apply to the principal and resource. Start from identity, then move outward along the hierarchy from the resource to its project, folders, and organization to collect every allow, deny, boundary, and constraint. Cloud Audit Logs support this work by recording high-risk changes such as grants of Organization Admin and Super Admin, Privileged Access Manager elevations, and entitlement expirations. Best practices for using service accounts in pipelines (opens in a new tab) emphasize the same check for automation identities, because a pipeline with *.setIamPolicy can expand its own access.

Common patterns explain most surprises without changing the target resource itself. An unexpected allow often comes from an inherited folder or organization grant, a Google Group membership, an overly broad default service account grant, or a *.setIamPolicy permission that let a pipeline or user expand its own access. An unexpected denial often comes from a deny policy, a PAB policy, an IAM Condition or tag mismatch, Domain restricted sharing blocking an external principal, unmanaged consumer accounts treated as external, or an organization constraint such as disabled key creation.

Key Facts

• Identity and Access Management (IAM) allow policies bind principals to roles on an organization, folder, or project, and grants inherit downward to all children unless constrained by conditions, deny policies, or access boundaries.
• A parent folder can contain up to 300 folders and folders can nest up to 10 levels deep, so one organization or folder grant can reach a very large set of descendant projects.
• Setting constraints/iam.automaticIamGrantsForDefaultServiceAccounts to False stops automatic Editor grants to default service accounts, while setting iam.disableServiceAccountKeyCreation to True blocks creation of long-lived user-managed keys.
• Organization policies enforce guardrails at request time, inherit downward with child override, and do not retroactively fix existing non-compliant resources.
• Granting any *.setIamPolicy permission has the effect of granting full access to that resource unless constrained by an IAM deny policy.