BeyondCorp and Teleport are both solutions that move away from traditional perimeter-based security, like SSH, towards a Zero Trust model.
Let’s see what a typical SSH login looks like in the wild. Say you’re a developer, Alice, and you need to access a staging server staging-db-01 to check some logs.
alice@laptop:~$ ssh alice@staging-db-01
# ... authentication prompts ...
alice@staging-db-01:~$
This works because staging-db-01 trusts Alice’s IP address, or more likely, that Alice presented a valid SSH key that’s been authorized on the server. The server knows Alice is Alice because she’s on the network, or has a pre-shared secret. This is the old way: trust based on network location or a static credential.
BeyondCorp, Google’s implementation of Zero Trust, flips this. It doesn’t care where Alice is, only who she is and what her device is like.
Here’s a conceptual flow for Alice accessing staging-db-01 via BeyondCorp:
- Alice’s Device: Alice’s laptop has an agent or is managed by an endpoint verification system. It reports its health, OS version, patch level, and whether it’s encrypted.
- Identity Provider (IdP): Alice logs into her company’s IdP (like Google Workspace or Okta) using multi-factor authentication (MFA).
- Access Proxy: Alice tries to reach
staging-db-01. Instead of connecting directly, she connects to a BeyondCorp Access Proxy. - Policy Enforcement Point (PEP): The Access Proxy consults the Identity-Aware Proxy (IAP) which checks:
- Is Alice authenticated and authorized by the IdP?
- Does her device meet the security posture requirements (e.g., patched OS, disk encryption enabled)?
- Is this access request within policy (e.g., only allowed during business hours, from a specific geographic region)?
- Resource Access: If all checks pass, the Access Proxy establishes a secure, ephemeral connection to
staging-db-01on Alice’s behalf. Alice never directly connects to the server.
Teleport offers a similar Zero Trust approach, but with a slightly different architecture focused on providing secure access to infrastructure (servers, Kubernetes clusters, databases, CI/CD systems).
Imagine Alice again, but this time using Teleport to access staging-db-01.
- Alice’s Workstation: Alice runs the Teleport client (
tsh).alice@laptop:~$ tsh login --proxy=teleport.example.com --user=alice # ... MFA prompt ... Proxy: teleport.example.com Node: staging-db-01 User: alice Roles: developer - Teleport Cluster: The Teleport client authenticates Alice against the Teleport Auth Server (which acts as the IdP and policy engine). This involves MFA.
- Access Request: Alice requests access to
staging-db-01. The Teleport Auth Server checks Alice’s roles and policies. - Short-Lived Certificate: If authorized, the Auth Server issues Alice a short-lived SSH certificate (valid for, say, 12 hours) for
staging-db-01. This certificate is signed by the Teleport cluster’s CA. - Connection: Alice’s
tshclient then uses this certificate to connect to the Teleport agent running onstaging-db-01. The agent verifies the certificate against the cluster’s CA.
Crucially, Alice’s laptop never has a static SSH key foralice@laptop:~$ tsh ssh alice@staging-db-01 # ... no password or key prompt ... alice@staging-db-01:~$staging-db-01. The certificate is ephemeral and tied to her identity and role. The connection is brokered by the Teleport agents and Auth Server, not direct.
The most surprising thing about Zero Trust access, especially with tools like Teleport, is that it often simplifies the user experience while increasing security. Instead of managing dozens of SSH keys, users get a single identity that grants access to many resources based on dynamic policies and short-lived credentials. The complexity is moved from the user’s machine to the central control plane.
The core problem these systems solve is the implicit trust granted by network location. In the past, if you were "inside" the corporate firewall, you were generally trusted. Zero Trust assumes no implicit trust. Every access request, regardless of origin, must be authenticated, authorized, and encrypted.
BeyondCorp’s core mechanism is the Identity-Aware Proxy (IAP). It sits in front of your applications and services, acting as a gatekeeper. It intercepts all incoming requests and checks them against a set of policies defined by your identity and device context. It’s not just about who you are, but also about the state of the device you’re using. A compromised or unpatched device can be denied access even if the user’s credentials are valid.
Teleport’s approach is built around a central Auth Server and distributed agents. The Auth Server is the brain, managing identities, issuing certificates, and enforcing policies. The agents run on the resources you want to protect (servers, Kubernetes, etc.) and act as the trusted intermediaries. When a user connects via tsh, they’re actually talking to a Teleport agent, which then communicates with the Auth Server to validate the user and establish a secure tunnel. This allows for fine-grained access control and session recording.
The exact levers you control are identity, device posture, and network context for BeyondCorp. For Teleport, it’s primarily identity, roles, and the policies that map roles to resources, along with session recording and audit logging.
One thing that often catches people off guard with Teleport is how it handles SSH key management. Instead of distributing static SSH public keys to every server, you configure the Teleport agent on the server to trust certificates signed by the Teleport Auth Server’s private key. When a user authenticates via tsh, they receive a temporary certificate from the Auth Server. This certificate is what allows them to log in, and it’s valid only for a limited time, significantly reducing the risk associated with lost or compromised SSH keys.
The next step after implementing Zero Trust for SSH is often extending it to other protocols and services, such as Kubernetes API access or database connections.