Identity and Access Management (IAM) in Google Cloud controls who has access to which resources. The core security principle is least privilege: grant only the minimum permissions needed for a user, service account, or group to perform their job. This approach reduces the risk of unauthorized access or accidental damage across your cloud environment.
By default, Google Cloud automatically grants the Editor role (roles/editor) to default service accounts when they are created. This permission is overly broad and creates a security risk. To prevent this, apply the automaticIamGrantsForDefaultServiceAccounts organization policy constraint, which disables automatic role grants. This forces your team to explicitly assign only the necessary permissions to each service account, following least privilege from the start.
Tags are annotations you attach to resources that allow conditional policy enforcement. You can create policies that allow or deny access based on whether a resource has a specific tag. This gives you fine-grained control across the resource hierarchy: you can apply a policy at the folder level that only affects resources with a certain tag, while leaving other resources unaffected. Tags help you manage IAM policies and organization policies efficiently at scale without creating many separate policies.
When predefined roles do not match your needs, you can create custom roles by combining specific IAM permissions. Only allow a small number of highly trusted principals to edit custom roles, because anyone who can edit a custom role can add any permission to it, potentially gaining unlimited access. Some permissions must be granted together to be effective: for example, to update an allow policy, you need both getIamPolicy and setIamPolicy permissions. When building custom roles, examine the permissions carefully and combine only those required for the specific job.
Service accounts act as identities for automated processes, and securing them is critical. Never let users create or upload service account keys, because anyone with a key can authenticate as that service account. Avoid granting access to service accounts at the project or folder level, because this allows users to impersonate any service account in that scope. Use organization policies to disable service account key creation and key upload across projects or folders. Audit high-risk changes by using Cloud Audit Logs to monitor when accounts are granted high-risk roles like Organization Admin and Super Admin.
Conditional role bindings allow you to control access to specific resources by adding conditions to your allow policies. You can use resource attributes in a condition expression written in Common Expression Language (CEL) to control access based on the resource's name, type, and service. For example, you can grant a role that only applies to Compute Engine instances whose names start with a specific prefix. This gives even more precise control than a standard role binding, further supporting the principle of least privilege.
Organization Policy Constraints are centralized rules that act as guardrails for your Google Cloud resources. They are part of the Google Cloud Organization Policy Service and allow administrators to enforce security, compliance, and operational governance across the entire resource hierarchy (Organization, Folders, and Projects). A constraint creates a specific restriction, such as limiting which regions can host resources or what configurations are allowed. Policies are inherited by default, meaning a policy applied at the organization level automatically applies to all child folders and projects, ensuring consistent enforcement.
You can use two main types of constraints. Managed constraints are Google-provided rules for common scenarios, such as restricting resource locations (gcp.resourceLocations) or blocking the creation of external service account keys. For more granular control, create custom constraints using a YAML format and the Common Expression Language to specify the exact resources, methods (such as CREATE or UPDATE), and conditions that should be allowed or denied. For example, you could create a custom constraint that only allows Compute Engine VMs of specific machine types.
Implementing constraints involves several key steps. First, define the constraint as either a managed or custom constraint. If using a custom constraint, write the YAML file with the CEL condition. Next, create and apply an organization policy that references the constraint. This policy sets the enforcement to ON and attaches it to a specific resource in the hierarchy. Remember that policies applied at a higher node flow down to all descendants, but you can override this inheritance at a lower level (such as a Folder) if necessary, allowing exceptions within the overall governance structure.
Constraints are powerful tools for critical security controls. Use the iam.managed.allowedPolicyMembers constraint to enforce domain-restricted sharing, ensuring only principals from trusted domains can be granted IAM roles. Apply the automaticIamGrantsForDefaultServiceAccounts constraint to disable overly permissive automatic role grants. Create custom constraints to restrict TLS versions for APIs or control specific fields in resources like VPC networks or Binary Authorization policies. Each constraint moves the organization toward a more secure and compliant posture.
In Google Cloud, resource access is governed by hierarchical inheritance where policies propagate from parent resources down to descendants. The effective allow policy for any resource is the union of all directly applied permissions and inherited permissions from folders, projects, and the organization level. A DevOps engineer must analyze this cumulative effect because granting a broad role at a higher node means children automatically receive those permissions. To diagnose access issues, evaluate the entire resource ancestry to determine the exact origin of a principal's effective access.
The Organization Policy Service applies programmatic restrictions called constraints across the resource hierarchy. While these rules are inherited by default, administrators can deliberately override them at lower folder or project levels to meet unique workload needs. For instance, the restrict TLS versions constraint can be set at the organization level but later modified on a child folder to allow older versions. Understanding these hierarchy evaluation rules is critical for troubleshooting why specific resource actions are blocked or permitted downstream.
To avoid overly broad permissions, administrators use conditional role bindings to grant access based on specific resource attributes. This mechanism uses resource attributes—such as name prefixes, types, or services—to dynamically evaluate whether a principal can perform an action. By applying conditional policies, organizations enforce least privilege, ensuring users only access specific sub-resources even if they hold broader project-level roles. Troubleshooting these conditional bindings requires verifying that runtime resource properties perfectly match the Common Expression Language conditions defined in the policy.
Securing the resource hierarchy also involves restricting identity types through domain-restricted sharing and managing automated system credentials. Implementing the domain restriction constraint limits role grants exclusively to authorized Google Workspace or Cloud Identity domains. Additionally, disabling the automatic IAM grants constraint ensures that default service accounts are not automatically granted overly permissive Editor roles upon creation. Enforcing these foundational controls prevents unauthorized external access and mitigates the risk of privilege escalation within the organization. When a user reports unexpected access or denial, check the effective policy at each level of the hierarchy, verify any conditional bindings, and confirm that organization policy constraints are not blocking the intended actions.
Professional Cloud DevOps Engineer
Gauge your current knowledge
Gauge your current knowledge
StudyCerts
StudyCerts