Machine-to-machine Zero Trust is handled by mTLS and SPIRE. But humans — developers, DBAs, SREs — also need access to infrastructure. This is where traditional VPNs create a different class of Zero Trust violation.
The VPN Problem: Network-Level Access
When a developer connects to a corporate VPN, the VPN places their laptop "on the network." From that point, they typically have broad network-level access — they can attempt to reach any IP address on the internal network, not just the specific systems they need. This violates two Zero Trust principles:
- Least privilege: The developer gets access to the entire network segment, not just the specific database or server they need.
- Verify explicitly: The VPN authenticates the user once at login, then grants persistent network access. There is no per-resource authorization check.
If the developer's laptop is compromised while connected to the VPN, the attacker inherits full network access.
HashiCorp Boundary: Identity-Based Access
HashiCorp Boundary is an open-source tool that replaces VPN-style network access with identity-based, per-session access proxying. The key conceptual shift: instead of granting network access, Boundary grants access to specific logical targets (a particular database, a specific SSH server) based on the user's verified identity.
How Boundary works:
1. Authentication via Identity Provider. The developer does not connect to a VPN. They authenticate to Boundary using their existing corporate identity provider (Okta, Azure AD, Google Workspace) via OIDC. Boundary never manages passwords itself.
2. Authorization via Roles and Grants. Boundary has a role-based access model. An administrator defines: "Members of the 'DBRE' group in Okta can access the 'Production PostgreSQL Primary' target." The developer sees only the targets they are authorized for — not a list of IP addresses, but named logical resources.
3. Session-Based Proxied Connections. When the developer requests access to a target, Boundary creates a temporary, encrypted tunnel for that specific session. The tunnel is proxied through a Boundary Worker — a component deployed with network reachability to the target. The developer's laptop connects to the Boundary Worker, which forwards the connection to the database. The developer never has direct network access to the database subnet.
4. Session Recording and Audit. Boundary can record sessions (keystrokes, commands) for compliance and forensic purposes. Every access event is logged with the user's identity, the target, the timestamp, and the session duration.
Developer Laptop
|
| Authenticates via Okta (OIDC)
v
Boundary Controller
|
| Checks: Is Alice in the DBRE group?
| Is DBRE group authorized for 'Prod PostgreSQL'?
| YES → Create session token
v
Boundary Worker (has network access to DB subnet)
|
| Proxied, encrypted tunnel
v
payment-db (private subnet, no public ingress)
Boundary vs. VPN: The Key Difference
A VPN gives you a network. Boundary gives you a connection to a specific resource. With a VPN, you get access to 10.0.0.0/16. With Boundary, you get access to Production PostgreSQL Primary for the duration of your session. When the session ends, the tunnel closes. There is no persistent network foothold.
Interviewers in platform engineering roles often ask: "How would you give a contractor temporary access to a production database for a one-time debugging session without giving them VPN access?" The Boundary answer is: create a temporary Boundary account or add them to a scoped group in the identity provider, grant that group access to the specific target, and set a session time limit. After the session, revoke the group membership. The contractor never touches the network directly, every command is logged, and access is automatically time-bounded.