Teleport 6.0 Brings Identity-Aware Access to Databases Behind NAT
If you have PostgreSQL or MySQL databases running behind NAT in multiple environments, this release of Teleport is worth downloading and playing with.
In this release, we added support for the PostgreSQL and MySQL wire protocols, so now Teleport users get the following streamlined workflow:
- Authenticate with their identities via single sign-on (SSO) and multi-factor.
- List and see all database instances running somewhere behind NAT, including AWS RDS or Aurora.
- Get instant access to them using CLI tools like
mysql, or Web UIs.
Meanwhile, Teleport ensures industry best practices for:
- Consolidating management of access requests
- Implementing role-based access controls
- Preventing data exfiltration
- Improving visibility into user behavior
- Auditing all activity
All of this works across your entire organization and regardless of where the database instances are running: an AWS/Google/Azure VPC, your own data center or an autonomous drone in the sky. The easy user experience is the same.
In this post, we’ll cover how Database Access works in more detail, but first, let me introduce Teleport to those who have never heard of it.
What is Teleport?
Teleport is an open source, identity-aware, access proxy with an integrated certificate authority. It is used by smart engineering teams to access various computing resources on public and private clouds, such as:
- SSH servers
- Kubernetes clusters
- Internal web apps
- MySQL and PostgreSQL databases (new in this release!)
How Does Database Access Work?
Teleport consists of just two dependency-free binaries: the
teleport daemon runs on
servers, and the
tsh CLI runs on clients. The server daemon can perform
- The Proxy accepts connections from the clients.
- The Certificate Authority (CA) issues short-lived certificates for clients.
- Sidecars maintain a persistent reverse tunnel to a proxy which allows clients to connect to databases that are running anywhere in the world.
The diagram below shows how this all comes together. The
teleport daemons are
shown as grey rectangles:
- When a user types
tsh login db-access.proxy.com, they trigger the login sequence. The Teleport proxy running on
db-access.proxy.comaccepts the login request and forwards the client to the company’s identity platform. This could be any identity provider: Google apps, GitHub, Okta, Active Directory, etc.
- After the user completes the login process, the Teleport certificate authority
CA) issues an x.509 certificate, filled with the user’s identity metadata (roles, etc.) which is returned to the client.
tshclient is now aware of all databases available to this user.
tshalso configures the user’s command line environment, so
psqlknows to talk to the proxy.
- Meanwhile, Teleport’s database service process (shown as “sidecar” in the diagram) is running on the same network as a database. The sidecar establishes an outgoing persistent reverse SSH tunnel to the proxy. These tunnels are how database instances are registered as “online”.
- When a user decides to connect to a specific DB instance, the connection goes from
psqlto a proxy, then (via an appropriate reverse SSH tunnel) to the corresponding sidecar and from there, via mutual TLS, to the target database instance.
What is not on the diagram is the audit log. Teleport will also be logging users’ activity across all databases.
In this video we have Roman, the lead engineer of the Teleport team, explaining the architecture and showing the end user experience of Database Access to a group of early adopters:
Why Database Access?
Teleport was originally born as a modern, identity-based way of accessing SSH servers, because we wanted the world to move away from archaic SSH keys, bastion hosts, VPNs, “server inventories” and the other pains of legacy SSH.
But SSH is not enough. Modern computing environments are getting more and more complex. In addition to SSH, our users want to access all kinds of computing resources in order to build software faster: Kubernetes clusters, internal web dashboards and, of course, databases!
Moreover, the location of these resources should be irrelevant. We are big believers in the future of environment-free computing, when the entire planet will feel like a giant multi-tenant supercomputer. That supercomputer must provide a simple and secure way of accessing it, and that’s what Teleport is evolving into.
Getting Started with Database Access
Teleport is available as an open-source download, fully-hosted cloud offering or as an enterprise package for running it on your own clouds or private data centers. You can sign up for a commercial offering or download an open source version on the getting started page.
Finally, if you want us to support other databases, tell us in our community Slack channel!
- Teleport vs. AWS SSM Session Manager
- In Search of a Perfect Access Control System
- Preventing XSS Attacks