GCP如何限制IAM用户至us-central1区域及基础Compute Engine实例类型？

Hey there! Since you're coming from AWS, you'll feel right at home with GCP's IAM tools—we can absolutely lock down your IAM user to us-central1 and restrict them to basic Compute Engine instance types, including explicit deny controls just like you're used to. Let's skip the org-level location restriction you already know and dive into the other robust methods.

This approach mirrors AWS's custom role + condition logic, but uses GCP's CEL (Common Expression Language) for conditions and explicit deny policies for hard restrictions.

Step 1: Create a Minimal Custom Allow Role #

First, build a custom role with only the bare minimum Compute Engine permissions your user needs—no broad compute.* permissions here. For basic instance management, include:

• compute.instances.create
• compute.instances.start
• compute.instances.stop
• compute.disks.create
• compute.networks.use (if they need to attach instances to a VPC)

You can create this via the GCP Console, gcloud CLI, or Terraform. For example, the gcloud command:

gcloud iam roles create BasicComputeUser \
  --project=YOUR_PROJECT_ID \
  --title="Basic Compute Engine User" \
  --description="Restricted access to basic Compute instances in us-central1" \
  --permissions=compute.instances.create,compute.instances.start,compute.instances.stop,compute.disks.create,compute.networks.use

Step 2: Attach a Region Restriction Condition #

When assigning this custom role to your IAM user, add a condition to limit actions exclusively to us-central1. The CEL expression here ensures the user can only interact with resources in that region:

resource.type == "compute.googleapis.com/Instance" && resource.location == "us-central1"

This works because GCP resources tag their location as the parent region (e.g., all zones under us-central1 inherit this region tag).

Step 3: Add an Explicit Deny Policy for Unallowed Instance Types #

To enforce the "only basic instance types" rule with explicit deny (which takes priority over any allow permissions), create an IAM Deny policy:

• Target your specific IAM user (user:your-user@example.com)
• Deny the compute.instances.create permission when the requested machine type isn't in your approved list

Example CEL expression for the deny condition:

request.machineType != "projects/YOUR_PROJECT_ID/zones/us-central1-*/machineTypes/e2-micro" && 
request.machineType != "projects/YOUR_PROJECT_ID/zones/us-central1-*/machineTypes/e2-small" && 
request.machineType != "projects/YOUR_PROJECT_ID/zones/us-central1-*/machineTypes/n1-standard-1"

Adjust the machine types to match your definition of "basic" (e.g., add e2-medium if needed).

If you want an additional layer beyond IAM, you can restrict the user to only use VPC subnets located in us-central1:

• Create a custom role that only allows compute.networks.use on us-central1 subnets (add a condition to the role assignment for this permission)
• Since all Compute instances must attach to a subnet, this blocks the user from creating instances in other regions where they don't have subnet access

• GCP's IAM Deny policies are equivalent to AWS's explicit Deny statements in IAM policies—they take precedence over all allow permissions.
• CEL is GCP's condition language (instead of AWS's policy condition keys), but the logic is similar: you're filtering actions based on resource/request attributes.
• Always follow the principle of least privilege—never grant broader permissions than necessary, even with conditions in place.

内容的提问来源于stack exchange，提问作者shivaniverma6991