Teleport is a powerful tool allowing organizations to secure access to SSH servers and Kubernetes clusters via a centralized authentication method. However, if you need to secure access to databases, Windows servers or internal web applications in addition to Linux servers/Kubernetes, there are other options to consider. This blog post looks at a few Teleport alternatives and discusses the pros and cons of each.
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.
Use cases
- Centralized access to servers, databases, RDP, internal web apps, and Kubernetes.
- SSH access to any username across a cluster of servers.
Pluses
- 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
- Many key features are unavailable with Teleport’s agentless mode, such as cluster introspection. Additionally, agentless mode only works for access to databases and web apps but not for Kubernetes (i.e., still need an agent for that).
- 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. Even with Teleport Cloud (where the Teleport Proxy or Auth Server aren’t needed), the customer must still install an agent on every instance for the cloud service to work and have it set up in TLS tunnel mode. You also can’t record your sessions in the cloud; every session is recorded on the node the session happened on. This means you have to install fluentd on every instance and pipe the results of that session out to a SIEM.
- The Teleport GUI is only available on AMD64 MacOS and is still a beta product. There’s no Windows client; you must install Teleport separately.
- Backend configuration required to store audit logs (AWS S3 / DynamoDB, required by Teleport to store session logs) in the self-hosted offering.
- Complex pricing model.
Teleport vs. 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.
🕵 Learn more about the differences between Teleport and StrongDM.
Teleport Enterprise vs. Teleport Community Edition
Brief product summary
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
Because Teleport CE is nearly identical to the Teleport Enterprise version, the same use cases apply.
Pluses
Minuses
- The same minuses as the other version of Teleport apply.
- Because it’s available free, only community support is available.
- The free version is missing important enterprise features (see above).
- Only uses local users or GitHub for identity-based authentication.
Teleport vs. Bastion Host
Brief product summary
A bastion host is simply a Linux/UNIX server that mediates access to sensitive servers/database access by requiring the user to first log into the bastion host then ‘jump’ to additional resources in the network controlled by the bastion. Organizations simply need to set up an additional server that is both accessible from external sources and is able to connect to internal resources.
Use cases
- Mediate access to protected resources on a restricted network segment.
- Database clients and similar tools can work via bastion host by using port forwarding over the SSH connection.
Pluses
- Free, or nearly so: the only requirement is the cost for the hardware (or virtual server) underlying the bastion host.
- Straightforward access for users who are familiar with SSH.
Minuses
- Because all access to protected resources requires first logging in via command line to the bastion host, the user must have an account on the bastion and a certain level of technical acumen, especially if employing port forwarding for database access.
- The bastion host represents a single point of failure; if it is unavailable all resources behind it are inaccessible. Setting up multiple bastion hosts to mitigate against this possibility means another set of credentials to manage.
- In the case of problems, support is limited to whatever support may be available for the underlying OS running on the bastion host.
- Session logs and database/other protocol activity are not captured.
