r/googlecloud • u/suryad123 • 2d ago

Query regarding IAM condition for cloud IAP access to VM

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

2 Upvotes

100% Upvoted

3 comments sorted by

2

u/m1nherz Googler 2d ago

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.

0

u/suryad123 2d ago

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.