Our Recommendation
Being Google’s own reverse proxy, IAP receives first-class treatment and integration with GCP and other Google tools. You can consider using Google’s IAP if you are fully integrated with GCP and have no plans to ever deviate from Google’s ecosystem.
If you want a reverse proxy that is cloud service agnostic because you have other clouds (such as AWS or Azure) or supports a hybrid infrastructure, you will want to self-host Pomerium to avoid bandwidth and latency costs. Being self-hosted and deployed at edge means your infrastructure gets all of the benefits stated in the original BeyondCorp papers, not just the bits Google wants to have control over.
Strengths
Two paths well traveled — Like Pomerium, Google IAP supports both HTTP and TCP based services.
All in the family — Being a Google product, IAP is built to integrate with other Google Cloud Platform services and tools. In fact, if you are already fully vendor-locked and have no plans to stray from the GCP ecosystem in the future, IAP may be a good solution.
Weaknesses
Big Data is Watching — For IAP to inspect traffic, it must first decrypt your data. This exposes everything through a period of being clear-text on Google’s side, including passwords and cookies. The only way to avoid that is to self-host.
Wizard required — Additional configuration and maintenance is required to use IAP with multi-cloud apps. In fact, you shouldn’t use IAP with multi-cloud, because…
All that for a tunnel? — To support on-prem infrastructure, you will need to subject your infrastructure to a Virtual Private Cloud to make IAP work. The architecture forces you to backhaul data with a site-to-site tunnel, defeating the purpose of IAP in replacing VPNs and tunneling solutions.
Not deployed at edge — You will incur hidden latency and bandwidth costs when using Google’s IAP to secure applications and services not in the GCP ecosystem.
Poor authorization logic — Google IAP is limited to very simple authorization policies. This is in contrast to Pomerium’s rich authorization capabilities.
Evaluators Should Know
“Pomerium is the technology that everybody would want to use, but only Google has at this point.”
-- An ex-Googler Customer in the Fortune 500 (we can’t name them yet, but check back soon!)
Pomerium traces its lineage back to the original BeyondCorp and UberProxy. It is worth noting that IAP is not UberProxy.
Unfortunately, Google has a habit of keeping the best for themselves and selling a watered down version (Kubernetes is not Borg, Bazel is not the same as Blaze, etc.) . Luckily for non-Google organizations, Pomerium is the replacement being used by ex-Googlers to replace UberProxy.
But let’s talk about other limitations of IAP and BeyondCorp. We base our evaluation on a strict four-pillar criteria when evaluating access control solutions:
Usability: IAP provides clientless access. We're happy with this and give credit where credit is due.
Speed: IAP’s latency is only comparable to Pomerium for GCP-only infrastructure. Pomerium is considerably faster for non-GCP deployments.
Security: IAP decrypts all private information for inspection. Companies should be aware of this exposure to third party compromise.
Context-aware: IAP has limited context-aware access due to being limited to dynamic access using predefined conditions.
Usability
IAP provides clientless access similar to Pomerium. This is good news as we want to limit the usage of third-party clients on our devices given they can be a breach vector.
Yes, this is a competitor but we are happy with their clientless access approach. We strongly believe Security is Usability, and clientless access is a critical step to ensuring users do not cause cybersecurity erosion.
Speed
What incurs latency? Hops. What causes hops? Needing to backhaul data. When do you backhaul data? Tunnels.
While IAP is undoubtedly better within Google’s Cloud Platform, that advantage vanishes for any company with multi-cloud or hybrid on-prem infrastructure. To continue using IAP requires tunneling and that’s where additional latency adds up.
Here's the sample architecture pulled from Google's documentation. That IAP connector uses a tunnel to reach the on-premise service to backhaul the data to GCP, then serve it to the user. It works, but we want to reduce tunnel usage.
Security
Finally, Google’s a safe bet, right? But there’s a reason why after evaluating Google IAP and BeyondCorp, security-companies like ExtraHop chose to self-host Pomerium instead.
"Pomerium enables true zero trust security without getting in the way of workflow or productivity. The end user experience is simple and onboarding has never been easier. It solves all the problems plaguing network administration and security frameworks while being flexible enough for any tool or application.
As a plus, it’s self-hosted so the Pomerium team cannot mess with your instance. SaaS-based Zero trust services must by design decrypt your traffic to provide functionality, meaning you are trusting them as a MITM. We want our traffic, our secrets, our authentication cookies to be protected even from our vendors. Our security is in our hands, using a reliable product."
~ Bri Hatch, Director of IT Operations at ExtraHop
A commonly overlooked aspect of 3rd-party hosted proxy solutions is SSL inspection. While any proxy responsible for continuous verification must necessarily do this (it’s impractical to inspect encrypted data), you are directly subjecting yourself to a potential man-in-the-middle attack with hosted solutions. Your data is exposed in clear-text, including sensitive data like passwords and cookies.
Remember when Google’s cloud was hacked? It’s unnecessary exposures like these that put organizations at risk of 3rd-party compromise.
This is why Pomerium offers self-hosted options, where organizations can control where data goes.
Context-Aware
IAP has a limited context-aware access feature for provisioning dynamic access levels based on predefined IAM conditions and end-user or device attributes.
Context-aware access matters because it is no longer reasonable to make access decisions based on user identity alone. Instead, access control solutions should have access to data that would better inform the context surrounding otherwise legitimate user activity. The access policy should integrate that data into access decisions when deciding if an impending action should be executed, completing the full circle of all four pillars to your access solution.
While undoubtedly useful, this is just a small form of context compared to Pomerium’s full integration model, where all information available to the organization can be integrated to make context-aware access decisions.
Pulled Plug?
Have an added bonus to consider when evaluating: while Identity-Aware Proxy and BeyondCorp haven’t joined the Killed by Google list yet, evaluators should be aware of Google’s consistent rug-pulling track record.
Note: How fun that while writing this, Google announced the end dates for three products. Google Domains being sold off was not in our bingo sheet, but it goes to show that nothing is sacred.
With Google products enjoying an average life-span of 4 years, it would be a waste of resources to implement IAP or BeyondCorp only to need to undo it several months down the line. Pomerium is open-source and available forever — no rug-pulling.
Pomerium’s place as an open-source context-aware reverse proxy helps prevent ransomware attacks on internal services and resources. Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without requiring a corporate VPN. The result is:
Easier with clientless access.
Faster by being tunnel-free and deployed where your apps and services are.
Safer because every single action is verified before allowed to execute.
Tailored to your organization’s needs by integrating all data for context-aware access.
Give Pomerium a try today!
