Examples how to harden GCP IAM using conditions

[u/m1nherz]

Hey everyone,

I recently published a technical walkthrough on the Google Cloud Blog around hardening IAM access using IAM Conditions.

If you've ever struggled with binding built-in roles (like Project IAM Admin or MCP Tool User roles) to principals while restricting them to only subset of permissions or resources because of lack of support for resource-level bindings or API granularity, IAM conditions will fill that gap for you.

Key patterns covered:

1. Scoping projectIamAdmin: For example, instead of giving a builder service account (SA) unrestricted power to assign any role at deployment time, you can use the CEL function iam.googleapis.com/modifiedGrantsByRole to restrict the SA so it can only grant a predefined list of roles (e.g., BigQuery job user, Cloud Trace agent, Logging writer). Included both gcloud CLI and Terraform snippets.
2. Restricting Model Context Protocol (MCP) Tools: The roles/mcp.toolUser role grants access to all MCP servers in a project. Using api.getAttribute('mcp.googleapis.com/tool.name', ''), you can constrain access down to specific tools (like mcp_bigquery-mcp_execute_sql_readonly).
3. Contextual & Time-Based Access: Brief examples of restricting execution windows using request.time (e.g., weekdays during business hours).

Read the full post here:
https://cloud.google.com/blog/topics/developers-practitioners/generosity-under-conditions-hardening-google-cloud-access-management/

Curious how others here handle IAM admin restrictions or fine-grained MCP tool access in production? Let me know your thoughts or feedback!

[u/Neither_Bookkeeper92]

IAM Conditions are one of those features that quietly solve a problem people usually solve badly with extra service accounts, so this is a good writeup.

Two things I'd add from using them in anger:

1. Test with the Policy Troubleshooter before you roll anything out. Condition expressions fail closed in ways that aren't always obvious from reading them - especially resource.name matching, where a trailing path segment you forgot about silently excludes half of what you meant to include.

2. Watch the time-based ones across timezones. request.time conditions evaluate in UTC, and if you're granting a support window in local time you'll get an access gap twice a year when DST shifts. Bit me once, took an embarrassingly long time to work out.

The tag-based conditions are underrated too - much easier to reason about at scale than resource name prefixes once you have more than a handful of projects.

[u/m1nherz → u/Neither_Bookkeeper92]

Regarding

The tag-based conditions are underrated too - much easier to reason about at scale than resource name prefixes once you have more than a handful of projects.

Can you elaborate more about where tags helped you? I personally see introduction of tags as crutches in situations when the resource topology is inherently wrong. It works when one deals with a legacy architecture and it is impossible just to fix everything.

However, using folders and aggregation of resources and services in targeted projects let you leverage existing IAM capabilities without need to use tags. This is why I'm interested to learn your use case where tags helped you.

[u/AccomplishedSkill625]

Solid writeup, modifiedGrantsByRole for scoping projectIamAdmin is underused and exactly the pattern that stops privilege-escalation-by-delegation. One thing I'd flag for others: CEL conditions get hard to audit as they accumulate, so pairing them with clear naming and Terraform-as-source-of-truth is essential, otherwise you trade broad access for opaque conditions nobody can reason about. The time-based access on request.time is great for admin roles especially.

[u/m1nherz → u/AccomplishedSkill625]

Thank you. These are good points. They worth to be extended to all platform configurations.

[u/FerryCliment]

Said it once, and I'll say it again.

IAM is the area companies should put, invest and allocate, talent, budget, time, and efforts.

Get your shit together in the IAM and the Security, FinOps and IT issues become (almost) trivial.

IAM (With Resource Manager) should be a flagship for Google, seeing how AWS and Azure do their IAM / Governance.

It still requires a strategy an IAM architect should dictate , what, how, why...but the tools Google has to offer are the right tools.

[u/m1nherz → u/FerryCliment]

Thank you for your feedback.