BeyondCorp, Federal Zero Trust Architecture Strategy and Teleport

"Crunchy on the outside, chewy in the middle". That's how Google described its perimeter-based security[1] in the aftermath of Operation Aurora. Operation Aurora[2] targeted high-profile companies such as Google, Adobe, Akamai, Rackspace, etc., with said primary reason of modifying the source codes. In response, Google initiated a perimeter-less and trustless access control system now popularly known as BeyondCorp. BeyondCorp comes from a realization that VPN perimeter network security is obsolete. As soon as an attacker breaches the perimeter, they have unrestricted access to the resources.

Zero trust has been hyped up in recent years, and with the release of a memorandum discussing federal Zero Trust Architecture (ZTA) strategies[3], zero trust has entered mainstream at the government level. Although the memo focuses on government agencies, it has a clear structure and strong foundations that apply to any modern company.

BeyondCorp is the first real-world implementation of the zero trust architecture for access control at large scale. What works for Google surely works for most use cases, at least at the infrastructure operation level. Since then engineers' workflow and infrastructure environments have evolved, and the security and operational model around which BeyondCorp was first designed in 2014 is no longer sufficient.

We launched Teleport as an open-source project in 2015[4] to help engineers secure access to their infrastructure. The security strategy behind Teleport's product has always been to improve both the speed and security of developer access to infrastructure while adhering to the core concept of BeyondCorp and zero trust architecture.

Teleport has grown a lot in the past few years. With the release of the U.S. government's ZTA strategy memo, it is a good time to review how Teleport implements and extends both the BeyondCorp and ZTA.

In this post, I will first revisit the core pillars of both BeyondCorp and the ZTA strategy memo, then compare these pillars with Teleport's capabilities.

Four Pillars of BeyondCorp

In BeyondCorp design, only users with verified identities and trusted devices can access registered services through an identity-aware proxy with centralized access control.

Let's review BeyondCorp's four core pillars:

Pillar One: Device identity

Device identity is a cornerstone of BeyondCorp strategy.

Each user device has to be registered within the inventory and identified with a strong cryptographic primitive — a security module. Only registered devices with up-to-date version and security patches have access to the infrastructure. Each device gets a special certificate with a private key stored securely, usually on TPM or other secure enclave.

Pillar Two: User database and SSO

BeyondCorp implementation needs an SSO identity provider and a centralized database that stores groups of the organization. As users join and leave the organization, move to new teams and assume new roles, the access system will reflect those changes automatically.

Pillar Three: Removing trust from the network and always-on access control

In the BeyondCorp world, there is no difference between local and remote access. The access control engine always evaluates access from any client to any application. Access is always encrypted and authenticated, all the time.

The engine may apply different requirements based on device location and the importance of application.

Pillar Four: Internet-facing access proxy

All access is performed through an internet-facing access proxy that continuously validates clients' credentials. This is a critical and often omitted part of the BeyondCorp implementation. Without a centralized access proxy in place, it is hard or impossible to achieve consistent validation of clients' devices, control connections, and implement access policies.

Very often, we hear the argument that centralized proxies are a single point of failure.

We do not see this being the case[5]. Distributed organizations are deploying IAP proxies all over the world in a highly available manner. Without an identity-aware proxy, the attack surface is just too large, as suddenly all servers, databases, Kubernetes clusters and other resources are in scope of internet access.

The traditional alternative is to protect access to internal resources using a VPN, but with an IAP, this step adds complexity with no additional gain.

Five pillars of federal zero trust architecture (ZTA) strategy

The Federal zero trust architecture strategy strongly emphasizes protection from phishing attacks using multi-factor authentication to eliminate weak second factors. It is likely influenced by the latest spike of phishing attacks on government websites.

Let's dive into the five pillars of the zero trust framework: identity, device security, network security, application and workload, and data security. Let's also cross-reference these pillars with BeyondCorp.

Pillar One: Identity

Identity with phishing resistant MFA

Zero trust requires a centralized identity provider with single sign-on, a common deployment strategy today.

It is great to see the author's focus on phishing-resistant MFA for everyone and a clear recommendation to give up on rotation of passwords and using special characters that lead to weaker passwords, paving the way for passwordless access to the infrastructure.

We think it is critical to phase out old-school MFA systems, not only SMS but one-time password tokens that are prone to MITM and prompt-bombing attacks.

The authors require using at least one device-level signal when accessing any application and require MFA checks to be integrated per application layer instead of being used one time to access the network. The memo calls out Personal Identity Verification (PIV[6]) and WebAuthn[7] standards explicitly.

Single factor short-lived credentials are not a substitute for strong device-authenticated access.

At all times, user role and access permissions should be evaluated when performing the access. Here it again rhymes with the BeyondCorp paper that emphasizes SSO and continuous updates of users' roles and organizations.

User authorization

The memo authors put more emphasis on the specifics of the authorization, requiring the system to use more modern attribute-based access and check access permissions at every attempt of access.

System administrators are recommended to move away from static RBAC access to a combination of ABAC and RBAC using user identity, attributes of the resource, and environment.

Pillar Two: Devices

The ZTA strategy memo brings device security into the scope of secure access and focuses on device inventories, device verification and device security health.

Inventory

It is critical to have a complete inventory of devices configured with an endpoint security system. System administrators need to have a complete picture of all devices and users participating in access.

The authors recommend configuring endpoint security and prefer thin clients with a least-privilege design that limits computing. We have seen this pattern emerge in the largest organizations, with Chromebooks and browser-based access used as the preferred mode of accessing infrastructure and critical data.

Today's modern browsers are the most secure access clients because they use advanced security techniques like sandboxing. We believe that more and more clients will be using Chrome or Chromium-based systems to access critical infrastructure.

The pressure to constrain and control the clients will lead to widespread adoption of thin clients, with most modern corporate clients being closer to old-school terminal mainframes, or Larry Ellison's vision of thin terminals connecting to the powerful corporate workstation.

Pillar Three: Networks

Encryption

With zero trust architecture, all traffic is encrypted end-to-end.

The memo focuses on DNS and HTTPS traffic encryption with FedRAMP-compliant cryptography implementation, most likely because that's a serious issue in today's government networks. The authors mention encrypting email traffic as well. However, in real-world non-government scenarios, email encryption is not used or deployed.

The authors put emphasis on using modern crypto, avoiding static keys and credentials. They recommend deploying traffic inspection and monitoring with caution traffic inspection and analysis, as weak monitoring tools can themselves be compromised.

Isolation

The authors recommend multiple strategies to isolate server and network environment resources and prevent lateral movement — if an adversary compromises one application, they should not exploit this vulnerability to gain access to another application.

Network isolations are basic sets of security control. Networks should be designed and configured with proper use of VPC and micro-segmentation. Network isolation should also be considered in terms of access control level because access control systems like VPNs usually have blanket access to all the infrastructure resources. So the access control system must also maintain logical isolation between resources in a one-to-one fashion and a context of identity.

Pillar Four: Applications and workloads

Treat each app as internet-connected, app sec testing, vulnerability disclosure, and safely export apps to the internet — track the fleet of apps, and scan periodically.

We think the BeyondCorp paper offers a stronger design with explicit identity-aware proxy components that solves rate limiting, device verification, authentication, connection control, and reducing the load on the actual application.

The authors cover the idea of immutable workloads, which require constraining infrastructure-level access to servers and infrastructure, managing and auditing it.

The authors offer common-sense recommendations to avoid manual modification and use consistent deployments across many environments.

But this is a pretty broad and general set of recommendations that will be very hard to achieve in a short period of time. So far, out of hundreds of our most advanced customers at Teleport, we have only seen a couple of companies fully utilizing the immutable infrastructure.

The authors also offer good practices such as infrastructure as code (IaC) and continuous integration and deployment (CI/CD). However, when implemented wrong, the CI/CD system could become the main target for attack. See the example of a supply chain attack on SolarWinds.

Pillar Five: Data

Categorization of the data

Hackers breach systems to gain access to private and important information. That's why ZTA strategy memo authors focus on discovery, classifying and protecting sensitive data.

This approach requires categorizing data properly and having the ability to audit any data access through the cloud and self-hosted infrastructure.

The ZTA strategy memo recommends detecting anomalous behavior with ML. This is a futuristic goal but is hard to achieve in a short period of time.

Meanwhile, there are easier techniques that users can deploy to secure access to their data, like label sensitive data and deploy dual authorization or moderating access in real-time to mission-critical production data.

Auditing access to data in the cloud

The ZTA strategy memo leans on cloud access control and reporting to audit access to the data. The authors offer good advice on encrypting data at rest in the cloud using customer-managed or cloud-managed encryption keys.

Centralized logging

As highlighted in the memo, the generic advice is to maintain centralized logging of all access to the data. While this is a good first solution, we would like to add that the logs should also be maintained in a tamper-proof system, as recommended in FedRamp access control.

Reviewing how Teleport implements federal zero trust architecture and BeyondCorp principles

Now, we will review Teleport's feature capability against the ZTA strategy memo with reference to zero trust maturity model[8]. The ZTA strategy memo is created for government agencies going through the process of upgrading their infrastructure. We think this model is useful for enterprises, as many of the same principles of security and data governance apply.

To recap, The ZTA strategy memo specifies several key pillars of secure access:

• Identity
• Device
• Network
• App workload
• Data

For each pillar, the maturity model presents three levels:

• Traditional: weak implementation or no implementation, status quo
• Advanced: mid-way implementation with some measures to centralize SSO, policies, some coordination, etc.
• Optimal: everything is automated with less privileged access and using dynamic tags to access critical data, centralized visibility, etc.

Teleport does not cover all pillars of the zero trust architecture strategy and covers some more completely than others. For example, Teleport offers a strong implementation of identity but does not encrypt data at rest, leaving this to the database implementation.

We have included capabilities that are not yet fulfilled by Teleport to give you a complete picture.

Pillar One: Identity

Authentication - Optimal

“Agency continuously validates identity, not just when access is initially granted”

Teleport provides strong authentication including per-session MFA and WebAuthn support that is tied to the authentication device. Teleport achieves this with a per-session MFA feature.

In the diagram below, Alice has to prove her identity and receive a certificate for every critical connection:

Not only does Alice have to prove her physical presence, but the connection to the target application is also authenticated with a security device ID that was used to initiate the connection.

This is where the BeyondCorp design is more advanced than the zero trust architecture strategy memo because it introduces IAP — an identity-aware proxy. IAP comes into play when all sessions initiated by a single device have to be terminated in case of a security incident, e.g., a stolen laptop. IAP gives context and control over every single connection made by users and devices, making it easy for admins to audit/block access at the per-device, per-connection level.

Teleport's IAP implementation authenticates[9] every single connection, reduces attack surface to one TLS port, and adds session and identity locking[10]. Our customers often deploy High Availability (HA) pair of proxies all over the world to provide low-latency access to their infrastructure for their distributed teams.

Every connection in Teleport is authenticated with mutual TLS or SSH. To authenticate, clients always present a certificate containing the device's ID, and all connections go through Teleport's IAP. Teleport has full control over the connection and the context.

The IAP approach helps security and infrastructure teams to respond to scenarios when the target commuting resource has been compromised. Admins can terminate all connections from all users to a single computing server, Kubernetes cluster or database.

Identity Stores - Optimal

“Agency has global identity awareness across cloud and on-premises environments.”

Teleport’s IAP[11] communicates the user's SSO identity to every single connection in the cluster. Teleport bakes in the user's SSO name into a x.509 or SSH client certificate, using mutual TLS or mutual SSH. That is why each connection has a complete trace of user’s access.

Unlike methods such as API Keys or JWT authentication that do not bind the token to the device or bearer tokens, mutual authentication with mTLS and SSH is much less prone to MITM attacks because both client and server verify each other's identity before establishing a mutual connection.

Risk Assessment - Advanced

“Agency determines identity risk based on simple analytics and static rules.”

Teleport provides strong authentication, including per-session MFA and WebAuthn support that is tied to the authentication device. Teleport achieves this with a per-session MFA feature.

In the diagram below, Alice has to prove her identity and receive a certificate for every critical connection:

As of now, Teleport does not do any advanced Machine Learning-based risk analysis. That’s why we marked implementation as advanced.

Visibility and Analytics Capability - Advanced

“Agency aggregates user activity visibility with basic attributes and then analyzes and reports for manual refinement.”

Teleport IAP intercepts all the supported protocols and aggregates all user and service activity in centralized audit storage.

The FedRamp standard that outlines U.S. government federal requirements for SaaS requires audit logs to be stored in tamper-proof storage, and we think it’s a good idea.

Hackers may try to remove their activity from the audit. Google’s Trillian[12] open source project builds tamper-proof verifiable logs on top of certificate transparency.

Teleport achieves tamper-proof audits by using S3 on AWS and Firebase on GCP in FIPS (Federal standard) and usual operating modes.

Automation and Orchestration Capability - Advanced

“Agency fully automates technical enforcement of policies. Agency updates policies to reflect new orchestration options.”

Most of Teleport’s large-scale deployments reflect a similar pattern — all identifying information is stored and managed in the identity provider.

Teams use automatic or semi-automatic labeling techniques to mark the resources - databases, Kubernetes clusters, etc.

Most of Teleport’s policies are highly templated[13] and reflect general rules - “Users who are members of their team can access resources labeled with their team as their own name”.

Whenever a policy is expressed in such a generic form, it does not have to be updated each time a user is added, removed, or assigned to a new group.

Teleport supports Just-In-Time access requests[14] to implement the principle of least privilege. On top of that, for accessing mission-critical data, Teleport adds moderated sessions[15] — a way to access a session only with an additional session moderator present.

Pillar Two: Device

When it comes to the client’s device security, Teleport offers advanced coverage of the ZTA strategy memo requirements with its Device Trust and Per-Session MFA features.

Teleport's Device Trust uses tamper-proof cryptographic storage and cryptoprocessor, Secure Enclave in Apple devices and Trusted Platform Module (TPM) in Windows/Linux devices, to authenticate client devices and provides admins with device inventory.

In addition to verifying client devices, Teleport adds on WebAuthn and FIDO for additional device and user authentication. In its most restricted configuration, Teleport requires registered device and authenticates every session with a WebAuthn biometric device with a certificate issued for the organization[16].

In this mode, each session will only be initiated from the device with a second factor issued by the organization. Even if the user takes the security device and plugs it into another computer, it won't be enough, as Device Trust will require the computer to be registered by administrators.

In this section, we will assume that administrators use a configuration of Teleport with Device Trust, WebAuthn, attestation, and require per-session MFA for all sessions and used in conjunction with Endpoint Management solutions, like Jamf or Intune.

Compliance Monitoring - Advanced

"Agency employs compliance enforcement mechanisms for most devices."

Teleport keeps and verifies the devices inventory. Admins can sync, add or lock access of devices that are out of compliance. Teleport relies on endpoint security tools to verify device posture.

Data Access - Optimal

“Agency’s access to data considers real-time risk analytics about devices. ”

With Teleport admins can require that only registered devices are accessing critical data. In addition to that, administrators can lock the devices that are out of compliance with Teleport's CLI or API.

Asset Management - Optimal

“Agency integrates asset and vulnerability management across all agency environments, including cloud and remote.”

With Teleport, system administrators have the ability to track all client devices that are registered and used to access infrastructure. Combined with endpoint security tools, admins can lock out access of devices that are vulnerable or out of compliance.

Visibility and Analytics Capability - Traditional

“Agency’s device management relies upon manual inspections of labels and periodic network discovery and reporting.”

Teleport does not provide any capabilities to monitor device fleets.

Automation and Orchestration Capability - Traditional

“Agency manually provisions devices with static capacity allocations.”

Governance Capability - Traditional

“Agency manually defines and enforces device acquisition channels and establishes and implements inventory frequency policy. Device retirement requires extensive sanitation to remove residual access and data.”

Teleport does not offer any procurement and device acquisition channels, leaving this up to the IT departments of the organization.

Pillar Three: Network/Environment

Network Segmentation - Advanced

“Agency network architecture consists of fully distributed ingress/egress micro-perimeters and deeper internal micro-segmentation based around application workflows.”

Teleport’s trusted clusters and TLS and SSH tunnels provide strong segmentation of networks. For example, with Teleport trusted clusters, organizations can segment access per datacenter and environment and invite external organizations:

Agency includes basic analytics to proactively discover threats - Traditional

“Agency includes basic analytics to proactively discover threats.”

Although Teleport records session events and activities at the protocol level, Teleport does not have a built-in method of audit-rich analytics to discover threats. Instead, Teleport supports forwarding these events to security information and event management systems (SIEMS) to raise alerts on suspicious activity or suspicious patterns. Teleport can forward structured audit logs to all major SIEMs; for example, Elasticsearch, Splunk or Datadog.

Encryption - Optimal

“Agency encrypts all traffic to internal and external locations, where possible.”

Teleport encrypts traffic end-to-end with strong mutual authentication for all protocols it supports — databases, windows RDP, SSH, HTTP.

Visibility and Analytics Capability - Advanced

“Agency integrates analysis across multiple sensor types and positions with manual policy-driven alerts and triggers.”

Teleport's protocol-level session event and activity recording give audit-rich visibility over access events. However, Teleport does not bake in any special alerts but makes it easy to export structured data to most modern SIEMs to set up alerting and monitoring.

Automation and Orchestration Capability - Optimal

“Agency network and environment configurations use infrastructure-as-code, with pervasive automation, following (CI/CD) deployment models.”

Teleport does not itself implement CI/CD, but makes it possible for CI/CD systems to use the same principles of passwordless, device-authenticated access with Machine ID[17]. All Teleport policies are expressed in code via Terraform or Kubernetes CRDs.

Governance Capability - Optimal

“Agency uses automated discovery of networks, devices, and services, with manual or dynamic authorization and automated remediation of unauthorized entities.”

Teleport automatically discovers, provisions, and de-provisions resources on cloud and on-premises infrastructure to a common resource catalog and labels resources into categories based on cloud or on-premises metadata.

For example, Teleport can discover databases on AWS via DB auto-discovery on AWS[18] or Windows Desktops via AD.

Notable Mention - DNS security

Security of DNS is a big topic in the ZTA strategy memo. This is likely due to the fact that DNS is very commonly used to discover and register computing resources and web apps. There are several fundamental issues with DNS though. Putting encryption aside, DNS does not provide out-of-the-box access control and access policy mechanisms to control search, visibility and discovery of resources.

That is why Teleport replaces usual DNS resolution with an internal service catalog search and can find resources by labels or hostnames.

This search is only available once the user is authenticated and is subject to access controls, providing stronger security than DNS over HTTPs.

Pillar Four: Application Workload

Access Authorization - Advanced

“Agency’s access to applications relies on centralized authentication, authorization, monitoring, and attributes.”

Teleport parses and inspects every protocol it supports — HTTPs, databases, desktops, SSH and Kubernetes. It is aware of the identity of the user and has visibility into resource attributes. This insight gives Teleport the ability to control access, record and audit per-application session.

Threat Protections - Traditional

"Agency threat protections have minimal integration with application workflows, applying general purpose protections for known threats."

Teleport Application Access eliminates many common threats from OWASP Top 10, password brute-force attacks, and other scanning attacks. For example, Java web apps running behind Teleport were not affected by Log4j scans. Teleport prevented unauthenticated scan attempts from external bots.

Teleport does not do any advanced WAF-level vulnerability scanning.

Accessibility - Optimal

“All applications are directly accessible to users over the internet.”

Teleport removes the need for corporate VPNs. In Teleport, every connection is either mTLS or SSH, and the Teleport proxy is identity-aware. It intercepts and authenticates, and authorizes every connection to the target computing resource.

Without IAP, infra admins would have to wrestle with the security of their DNS and protect each resource individually.

Teleport provides basic measures against scans and basic brute-force attacks, such as rate limiting, but it should be deployed behind a service that provides DDoS protection when exposed to the internet.

Application Security - Traditional

"Agency performs application security testing prior to deployment, primarily through static and manual testing methods."

Teleport does not provide any application security features such as SAST, or DAST.

Visibility and Analytics Capability - Traditional

"Agency performs application health and security monitoring in isolation of external sensors and systems."

Teleport makes it easy to discover apps and prevents unauthorized access, but it does not perform any additional security monitoring of apps.

Automation and Orchestration Capability - Advanced

"Applications can inform device and network components of changing state."

Teleport application access can register applications and communicate their status via dynamic tags. These tags will be used to control access to the application in real-time.

Governance Capability - Advanced

"Agency has updated policies and centralized enforcement."

With Teleport App access, users can have centralized enforcement of access policies to their applications across all clouds and on-premises environments.

Pillar Five: Data

Inventory Management - Advanced

"Agency primarily inventories data manually with some automated tracking. Agency performs data categorization using a combination of manual and static analysis methods."

"Agency continuously inventories data with robust tagging and tracking. Agency augments categorization with machine learning models."

Teleport Database Access allows engineers to automatically discover databases, audit access to the data and use dynamic labels to label databases based on the importance of the data.

Admins can write policies using DB labels and user identity to limit access across multiple clouds and on-premises.

Teleport does not perform any machine learning data categorization.

Access Determination - Advanced, partially Optimal

"Agency governs access to data using least privilege controls that consider identity, device risk, and other attributes."

"Agency’s access to data is dynamic, supporting just-in-time and just-enough principles, and continual risk-based determinations."

Teleport provides granular just-in-time access controls configurable with roles, resources and short-lived certificates and authenticates users per session with their WebAuthn compatible security device.

Encryption - N/A

Teleport does not encrypt the database’s data at rest, leaving this to database administrators and implementations, but makes sure access to the data is encrypted in transit with strong encryption.

Visibility and Analytics Capability - Advanced

Most of the agency’s data are inventoried and can be accounted for since the last inventory update. Analytics are limited to plaintext data.

With Teleport Database Access, admins can view commands executed by database clients. This enables visibility over data access stored in a database.

Automation and Orchestration Capability - Partial Advanced

Agency runs scheduled audits that locate high-value data and analyze access controls. There is limited automatic orchestration to apply controls and ensure backups are in place.

Teleport does not provide any data backups for external databases; it allows to define access controls based on data labels and user identity and audits all data.

Governance Capability - Advanced

"Agency enforces data protections through mostly technical and some administrative controls. Data categorization and data access authorizations are defined with a method that better integrates diverse data sources."

With Teleport, all databases are registered in a dynamic resource catalog. Teleport controls access to the database regardless of its location. Teleport connects, authenticates, and authorizes a user’s connection, such as to an RDS database on AWS, on-premises Postgres behind a firewall, or MSSQL running on Azure. Teleport does not rely on passwords and API keys and instead always uses appropriate passwordless authentication, e.g., IAM on AWS or client certificates or AD Kerberos on Windows.

As databases register and deregister, Teleport updates database dynamic labels and uses the labels to apply access controls.

Teleport databases are never accessed directly, always through an identity-aware proxy that enforces authentication with mutual TLS.

How Teleport extends BeyondCorp and Federal Zero Trust Architecture

Both BeyondCorp and ZTA strategies outline several core components of secure access — device security, networking and encryption, centralized and dynamic access control, and data security.

Teleport implements many of the core security designs as specified in both the BeyondCorp and ZTA strategies. But Teleport is focused on infrastructure access. This focus has allowed us to extend the security and align with modern DevOps-driven infrastructure operation workflow.

Below are the major extensions Teleport offers over both BeyondCorp and ZTA strategies.

Shifting left with access policy as code and modern tooling

Companies are starting to rethink their access strategy. We are observing a "Shift left" happening in modern teams. Access policies are critical to infrastructure security and should follow the same infrastructure-as-code principles. We believe policies should be expressed as code, audited and peer-reviewed, and linted with security controls.

Teleport implements policy-as-code with its Terraform and Kubernetes providers. Teleport's policies are declarative, and we have built cutting-edge tools[19] to verify and lint policies formally. Besides access policies, the product configurations can also be updated with YAML files allowing them to define and store these files in a source version control system like git. This feature allows proper tracking of change management, which often is susceptible to configuration drifts as the install base and usage grows.

Further, we are seeing that many companies are deploying more innovative approaches to review access requests to critical infrastructure that engineers use. Instead of having a centralized, ticket-based system, modern infrastructure teams use peer-review (similar to pull request peer review) to review access to infrastructure. IT teams do not have to be a gatekeeper anymore; very often, they don't even have the right context to review all requests for elevated privileges.

Teleport has built just-in-time access that looks very much like GitHub pull requests to enable this trend. This feature also integrates with modern ChatOps tools like Slack, Mattermost, etc., and real-time operation tools like PagerDuty, limiting access to the time of day using PagerDuty support schedules.

Secure access to all infrastructure resources

Most of the time, teams only focus on protecting access to a few critical servers and corporate websites. But access to all the infrastructure resources should be treated similarly to access to corporate websites. Whether it's a web application, an SSH server, databases or any other infrastructure resources — the same rules apply — access to infrastructure resources should only happen from authorized, up-to-date devices with strong encryption and authentication that sits behind an IAP.

Some companies aspire to escape this problem with immutable infrastructure that developers never touch, but the reality is just not there, and in most companies, engineers still need access to their infrastructure.

Treating machine access same as user access

Both BeyondCorp and ZTA memo focus a lot on workers and their devices, the security of their computers, and access. But in the modern DevOps-driven operation, bots and services are involved more than manual operations. CI/CD systems are compromised as frequently and are often more vulnerable than users' computers. So machine access should also be treated as a first-class citizen for infrastructure access.

Teleport lets machines use short-lived certificates instead of commonly used API keys, audits and controls their access, just like any other client in the system.

Unify multi-cloud access

Infrastructure is a mix of multiple clouds and self-hosted, making IAM integration across multiple clouds and networks a nightmare. It is critical to unify access control across heterogeneous environments.

Teleport's access control policies are multi-cloud and integrate with the cloud's identity and access management providers, abstracting away differences and adding missing features, like connection control, dual authorization, and others, resulting in a single sign-on (SSO) experience to multi-cloud access.

Strong cryptographic foundation

In BeyondCorp implementation, short-lived tokens are issued after the SSO flow. Teleport replaces those with short-lived certificates because they establish mutual TLS (mTLS) and mutual SSH and are much harder to attack than tokens.

Tokens for authentication are not secure enough, especially for the large, dynamic multi-cloud infrastructure most companies use today. In the absence of strong cryptographic mutual authentication that works in distributed systems, customers' infrastructure ends up using weak authentication, like API keys, relying on shared secrets or a mix of multiple authentication systems. These authentication systems don't work well with each other, for example, Kerberos on Windows and IAM on AWS.

Teleport is built on top of a strong PKI foundation. Teleport implements a certificate authority that issues short-lived certificates for users and machines. Teleport automates CA lifecycle management and implements a certificate renewal bot, enabling these features to grow and adapt in large-scale infrastructure access.

Avoiding proprietary lock-in

Every cloud provider in the world wishes to be the only one out there with everyone using their API. Infrastructure access solutions are a critical part of infrastructure operation.

We strongly believe that such a critical, core piece of infrastructure should be independently audited and extended by companies. Not just for infrastructure access, but an open source solution with robust API and a reasonable business-friendly license is a must-have as a solid foundation for any infrastructure solution. This has, in fact, been one of the primary reasons we open-source Teleport.

End-to-end passwordless infrastructure access

We believe that secret-based authentication with passwords, API keys and tokens will be replaced with strong cryptographic authentication using biometrics and security devices. While most of the popular web applications are moving towards passwordless authentication, this is still far from reality for infrastructure access space.

Teleport supports passwordless authentication based on WebAuthn, Passkey and certificates, offering an end-to-end passwordless solution for infrastructure access.

Conclusion

Teleport implements Google's BeyondCorp strategy and extends it further with modern passwordless, shift-left patterns and brings the same Google-level features to everyone as an open source solution. Want to try Teleport? Sign up[20] for Teleport Cloud or download[21] the Teleport community-edition build (it's only a single-binary to run Teleport server!)

References:

• [1] https://blog.google/outreach-initiatives/public-policy/transparency-in-the-shadowy-world-of-cyberattacks/
• [2] https://en.wikipedia.org/wiki/Operation_Aurora
• [3] https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
• [4] https://github.com/gravitational/teleport
• [5] https://goteleport.com/blog/do-we-still-need-a-bastion/
• [6] https://www.nist.gov/identity-access-management/personal-identity-verification-piv
• [7] https://goteleport.com/blog/webauthn-explained/
• [8] https://www.cisa.gov/zero-trust-maturity-model
• [9] https://goteleport.com/docs/architecture/proxy/#identity-aware-proxy
• [10] https://goteleport.com/docs/access-controls/guides/locking/
• [11] https://goteleport.com/docs/architecture/proxy/#identity-aware-proxy
• [12] https://github.com/google/trillian#overview
• [13] https://goteleport.com/docs/architecture/authorization/#role-based-access-control
• [14] https://goteleport.com/docs/architecture/authorization/#just-in-time-access-requests
• [15] https://goteleport.com/docs/access-controls/guides/moderated-sessions/
• [16] https://goteleport.com/docs/access-controls/guides/webauthn/#step-13-enable-webauthn-support
• [17] https://goteleport.com/docs/machine-id/introduction/
• [18] https://goteleport.com/docs/database-access/reference/aws/
• [19] https://github.com/gravitational/rbac-linter
• [20] https://goteleport.com/signup/
• [21] https://goteleport.com/download/