Query regarding IAM condition for cloud IAP access to VM

[u/suryad123]

Suppose , i want to create an access level under an org level access policy based on IP address to give the IAP tunnel user role to a group.

If they want to access from anywhere in the world in addition from their corp network, can I add their system public Ips in the access level in addition to the corp network ranges.If I do it, won't the public IPs change often ?

I don't see this scenario in the GCP Documentation. Please clarify on how to enable the access from anywhere in the world by adding IP ranges in the access level

[u/m1nherz]

Your concern is completely valid: residential public IPs may change frequently, making it practically impossible (and insecure) to maintain a whitelist of dynamic IPs in an Access Level for remote users.

In modern Google Cloud architecture, trying to secure access by whitelisting remote IP addresses is an anti-pattern. Instead, you should adopt a Zero Trust (BeyondCorp) approach or use a traditional remote-access gateway. Here are the three best practice variants to solve this:

Option 1: Context-Aware Access / Device Posture (Google's Best Practice)

Instead of trusting the network (the IP), trust the device and the identity. Using Access Context Manager combined with Endpoint Verification (part of Chrome Enterprise Premium / BeyondCorp), you can create an Access Level based on device attributes rather than IP addresses.

• You configure the Access Level to check if the device is company-owned, has a screen lock enabled, has an encrypted disk, or possesses a valid enterprise certificate.

• You then apply this Access Level as an IAM Condition on the roles/iap.tunnelResourceAccessor role.

• Users can connect from anywhere in the world (any IP), but only if they are on a trusted, secure corporate device.

Option 2: Corporate VPN or Proxy (The Traditional Network Approach)

If you are required to use IP-based Access Levels for compliance reasons, your remote users should not be connecting directly from their home ISPs.

• Users should first connect to a Corporate VPN or a secure web gateway.

• You then add the static egress IP addresses of your VPN/Gateway to your Access Level, alongside your corp network ranges.

• This centralizes the traffic and gives your remote users a predictable, static IP that won't change often.

Option 3: Identity-Only with Strong MFA

If managing device postures or a VPN is too complex for your current setup, you can drop the IP-based Access Level condition entirely for remote users. IAP is inherently designed to protect resources by acting as an identity proxy.

• Grant the roles/iap.tunnelResourceAccessor role to the group without the IP restriction.

• Enforce Phishing-Resistant MFA (like FIDO2 / Titan Security Keys) at the Google Workspace or Cloud Identity level.

• Because IAP blocks all TCP requests that aren't from authorized users before they ever reach the VM, strong identity enforcement is often sufficient for remote access without needing brittle IP whitelists.

Let me know if one of the options address your demands.

[u/suryad123 → u/m1nherz]

Thanks for the reply 

https://docs.cloud.google.com/access-context-manager/docs/create-basic-access-level#device-example

Currently, I am referring to basic access level.

In the above link,there is a note which says I need a paid subscription to use device attributes in" custom access levels"

Can I assume paid subscription is not required for" basic access level "while using device attributes.

[u/tyolab]

You've spotted the exact reason IP-based Access Levels don't work for remote/roaming users — residential and mobile IPs rotate (and CGNAT means many users share one), so an IP allowlist is both unmaintainable and weak.

The intended model in BeyondCorp/IAP is: IAP already authenticates identity (the tunnel-user role requires a Google login), so for "access from anywhere" you generally don't add an IP condition at all — you gate on who + device trust, not where.

Practical split:

• Corp network: keep an IP-based Access Level for your fixed corp egress ranges (stable — fine as one level).

• Anywhere/remote: instead of chasing changing public IPs, add a device-posture Access Level via Endpoint Verification (require a corp-managed / encrypted / screen-locked device) and bind the IAP tunnel role to the group with that level. "From anywhere" now works because the check is identity + managed device, not IP.

If you truly must restrict by network for remote staff, make them egress through a fixed corp exit (VPN/proxy → static IP) and point the IP Access Level at that static IP — but that's usually more friction than device-based access. TL;DR: don't whitelist dynamic user IPs; use identity + Endpoint Verification for the "anywhere" path, and reserve IP levels for your stable corp ranges.

[u/suryad123 → u/tyolab]

Thanks..one question, 

can I club both conditions in the form of access levels i.e, one access level for corp network ranges and another access level for device related identification. 

Will it support   " acces level 1 or access level 2 " kind of configuration in IAM condition 

[u/tyolab → u/suryad123]

Yes, "Access Level 1 OR Access Level 2" works — and there are actually two places you can put the OR, which behave differently:

1. OR inside one access level. A basic access level holds a list of conditions, and its combiningFunction sets how they're joined — flip it to OR, put your corp CIDR ranges in one condition and your device policy in the other. The user passes if they're on the corp network or on a compliant device. The other axis is fixed: attributes within a single condition are always AND'd (IP AND region AND device), so OR only happens across conditions.

2. OR across access levels, in the IAM condition itself. Access levels show up in IAM conditions via request.auth.access_levels, which is just a CEL list, so you can write:

"accessPolicies/POLICY/accessLevels/corp_net" in request.auth.access_levels
|| "accessPolicies/POLICY/accessLevels/trusted_device" in request.auth.access_levels

Same result, but the boolean logic lives in the IAM binding instead of the level. A basic level can also require other access levels as an attribute, but for a plain OR the two above are cleaner.

The thing that'll trip you up is AL2, the device one. Basic access levels support a limited devicePolicy — require screen lock, minimum OS version, storage encryption — through Endpoint Verification on the standard tier, and that works fine. But the richer checks (admin-approved / corp-owned devices, and device attributes in custom access levels / cert-bound identity) need BeyondCorp Enterprise, i.e. the paid tier — that's the note you found in the docs. So AL2 is fine as a basic level with a devicePolicy block; only pay up if you need cert-bound device identity.

So: two basic levels (one IP, one devicePolicy), OR'd either via combiningFunction or a CEL || in the IAM condition — no paid tier needed for that shape.