Alternatives to Google Cloud Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) is a Google Cloud Platform service that centralizes user access to SaaS applications and other cloud resources accessed by HTTPS. IAP secures authentication for requests made to virtual machines running on GCP and other cloud-based and on-premises applications, only granting access to users you authorize. With IAP, users can connect from untrusted networks without using a VPN. In this post, we go over a few Google Cloud IAP alternatives and the pros and cons of each.

However, if your goal is to centralize and secure access to multi-cloud infrastructure, including databases, servers, and Kubernetes, IAP may not be the best fit for your needs. In this article, we’ll discuss a few popular alternatives, addressing the strengths and weaknesses of each. But first, a quick look at the features you may want to consider.

Google Cloud IAP Overview

Brief product summary

Google’s Identity-Aware Proxy aims to increase security, allowing admins to establish and enforce access-control policies. The service simplifies access for cloud administrators and remote workers, eliminating the need for a VPN.

IAP provides a zero-trust access model for GCP resources such as Google Compute Engine and Google Kubernetes Engine (GKE) instances, allowing access only to users with the correct identity and access management (IAM) role. Additionally, you can use TCP forwarding to control access to SSH and RDP. With proper configuration, IAP will also authenticate to apps on other clouds and on premises.

Use cases

• Authentication for web applications and cloud resources.
• Access control for SSH and RDP.

Pluses

• SSH access available.
• RDP access available.
• Automatically creates an OAuth 2.0 client ID and secret.
• Easy to integrate with other GCP services.

Minuses

• Requires additional configuration to use with multi-cloud apps.
• Doesn't protect against activity within a project.
• Limited third-party integration.
• Initial setup is complex.

1. StrongDM

Brief product summary

StrongDM is a control plane to manage and monitor access to databases, servers, and Kubernetes. Their zero trust model means instead of distributing access across a combination of VPN, individual database credentials, and SSH keys, StrongDM unifies user management in your existing SSO (Google, Onelogin, Duo, Okta, SAML, etc...) and keeps the underlying credentials hidden. Neither credentials nor keys are accessible by end users. Because StrongDM deconstructs every protocol, it also logs all database queries, complete SSH and RDP sessions, and kubectl activity.

Use cases

• Faster onboarding- no need to provision database credentials, ssh keys, VPN passwords for each new hire.
• Secure off-boarding- suspend SSO access once to revoke all database, server access.
• Automatically adopt security best practices- least privilege, just-in-time access, audit trail.
• Comprehensive observability and visibility- log every permission change, database query, ssh & kubectl command.
• Vendor privileged access management-connect third-party vendors to resources with project-based access that automatically expires.
• Security and compliance teams-simplify HIPAA, SOC 2, SOX, ISO 27001 compliance certification.
• Modern Cloud PAM solution-built to support a variety of cloud networks, including public, private, multi-cloud, and hybrid.

Pluses

• Easy deployment - self-healing mesh network of proxies.
• No change to workflow- use any SQL client, CLI, or desktop BI tool.
• Standardize logs across any database type, Linux or Windows server, and Kubernetes.
• Graphical client for Windows and macOS.
• See and replay all activity with session recordings.
• Manage via a user-friendly web browser interface.
• Simple, straightforward pricing.

Minuses

• Requires continual access to StrongDM API for access to managed resources.

StrongDM’s G2 Reviews

• 51 reviews (at the time of writing)
• 4.8 / 5 stars

Read all of StrongDM’s G2 reviews here.

Pricing Information

StrongDM offers simple per-user pricing, starting at $70/license, including support for all resource types.

Users have the option to sign up for a free 14-day trial.

2. Okta Advanced Server Access (ScaleFT)

Brief product summary

Okta’s Advanced Server Access (ASA) provides privileged access management (PAM) for cloud-native infrastructure. Okta did not build this capability in-house; it came from an acquisition Okta made in July 2018 of a company called ScaleFT. ScaleFT’s original competition came from a company called Gravitational, and their product, Teleport. In general, it is an access and authentication proxy for RDP and SSH access. It allows administrators to set up access for users (grouped into teams) to servers, and implements role-based access control (RBAC) to allow differing levels of access per team to different servers.  Individual server credentials are not available to users, reducing the administrative impact of rotating and removing credentials.

Use cases

• Centralized access to SSH and RDP servers.

Pluses

• SSH access is available.
• RDP access is available.
• Single sign-on (SSO) for SSH/RDP and your identities in Okta.
• Authorized requests leverage single-use client certificate or web token scoped to the user and resource being accessed.

Minuses

• Okta’s software must be running on every server it manages access to.
• Complex setup: in addition to the ScaleFT software on each server, a ScaleFT Gateway and ScaleFT local client must also be built and maintained for each cluster.
• CLI-only client scares off non-engineers.
• User credentials are assigned ephemerally adding complexity to deployments and uptime.
• Backend configuration required to export audit logs to any 3rd-party.
• ScaleFT agent audit logs are only accessible through an early access enablement.
• Audit logs only cover SSH.
• No auditing for RDP.
• Complex pricing model.
• Pricing based per server, which gets extremely expensive in ephemeral environments or those with high-n servers.

3. Teleport

Brief product summary

Gravitational Teleport provides privileged access management (PAM) for cloud-native infrastructure. Teleport is an access and authentication proxy for SSH and Kubernetes API access. It's meant as a replacement for sshd and it works with existing OpenSSH clients and servers as-is. It allows administrators to set up access for users and groups to groups of servers, called clusters, and implements role-based access control (RBAC) to allow differing levels of access to different clusters. Individual server credentials are not available to users, reducing the administrative impact of rotating and removing credentials.

The open source Community Edition of Teleport is the same as the Enterprise edition, with the following exceptions:

• No RBAC.
• No SSO integration.
• No paid support available.

Use cases

• Centralized access to servers and Kubernetes.
• Granting user SSH access to the same usernames across a cluster of servers.

Pluses

For the Enterprise Edition:

• SSH access available via web UI on proxy server.
• Single sign-on (SSO) for SSH/Kubernetes and your organization identities via Github Auth, OpenID Connect or SAML with endpoints like Okta or Active Directory.
• Can use with an existing OpenSSH infrastructure.
• Teleport uses SSH certificate-based access with automatic certificate expiration time.

Minuses

For the Enterprise Edition:

• Teleport software must be running on every server to be managed by Teleport access.
• Complex setup: in addition to the Teleport software on each server, a Teleport Proxy and TeleportAuth server must also be built and maintained for each cluster.
• CLI-only client scares off non-engineers.
• User credentials are assigned across a full cluster rather than server-by-server.
• Backend configuration required to store audit logs (AWS S3 / DynamoDB, required by teleport to store session logs).
• Teleport agent audit logs are only accessible through the UI or backend storage.Complex pricing model.

For the Community Edition:

• Because it’s available free, only community support is available.
• Is missing important enterprise features (see above).
• Only uses local users or Github for identity-based authentication.