HashiCorp Boundary is an open-source identity access management (IAM) tool that facilitates secure user access to dynamic hosts and critical infrastructure across environments. However, if you need a simple and secure way to manage access to databases, Kubernetes clusters, cloud CLIs, switches, routers, or internal web applications, there are other services to consider. In this blog post, we’ll take a look at a few alternatives and discuss the strengths and weaknesses of each. First, a quick side-by-side comparison of the features you may want to consider.
Brief product summary
HashiCorp released Boundary in 2020 as an answer to Vault users’ need for a session management (as opposed to credential management) solution. The project aims to simplify onboarding and create a dynamic workflow for system access, especially in high-automation environments, by granting authenticated and authorized users access to sensitive systems. It uses the principle of least privilege, allowing developers and operators just enough access to perform the required job. This limits access to larger networks, reducing the risk of compromise. Boundary also monitors and logs session metadata.
- Hashicorp Boundary is open-source and free identity-based security.
- Role-based and logical service authorization.
- Uses SSO to manage, onboard, and offboard users.
- Integrate with existing tools and APIs.
- Dynamic resource catalogs.
- Planned integration with Terraform, AWS/GCP/Azure, Kubernetes for live updating of catalogs based on tags in v0.2.
- Dynamic credentials.
- Integration with Vault and others for end-to-end dynamic credentials.
- Authenticate with identity provider already in use.
- Tools are confusing.
- Complex setup with lots of "moving parts". Users have trouble figuring out what to run together and how to integrate.
- Requires a third tool, Consul, to manage services and machine-to-machine access.
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, 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.
- Faster on-boarding- 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, ephemeral permissions, audit trail.
- Comprehensive logs- log every permission change, database query, ssh & kubectl command.
- Easy deployment - self-healing mesh network of proxies that auto-discovers available database, ssh nodes & Kubernetes clusters.
- 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.
- Requires continual access to strongDM API for access to managed resources.
Teleport (Community Edition or Enterprise)
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 different 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.
- Role-based access controls.
- Use existing identity management tools.
- Record all session activity into auditable logs.
- Open-sourced and free.
- Gives users secure access to resources.
- No contracted support available on the free product.
- Teleport software must be running on every server to be managed by Teleport access.
- Complex setup.
- 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 Enterprise.
Brief product summary
A bastion, or jump, 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. The bastion host normally performs only security functions and is updated and audited often to ensure network security.
Organizations need to set up an additional server that is both accessible from external sources and is able to connect to internal resources.
- Mediate access to protected resources on a restricted network segment.
- Database clients and similar tools can work through a bastion host by using port forwarding over the SSH connection.
- The latest security is updated and the computer typically includes intrusion detection software.
- Very affordable option - the price of a dedicated computer.
- Provides resource access to users through SSH.
- 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.