search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
17.42k stars 1.74k forks source link

Support Postgres/libpq SNI headers for targetting Postgres databases behind TLS multiplexer #28057

Open webvictim opened 1 year ago

webvictim commented 1 year ago

Currently, it's mandatory to use tsh db connect or tsh proxy db to connect to Postgres databases behind a Teleport cluster which has TLS multiplexing enabled. This is a worse experience for end users over just being able to construct their own Postgres configs. It also means that the output of tsh db config is incorrect when used with Teleport Cloud clusters.

Services like Neon are successfully using SNI extensions to target different Postgres databases behind a multiplexed endpoint.

There are more details on the exact TLS SNI implementation details and usage here: https://neon.tech/docs/connect/connection-errors#the-endpoint-id-is-not-specified

Teleport could implement this to make it possible to connect directly to the Postgres listener and be routed to the correct database without the need for tsh db connect or tsh proxy db. This benefits any Teleport user using TLS multiplexing (for example, all Teleport Cloud customers) and gives them an easier end-user experience which is more consistent with a self-hosted cluster.

greedy52 commented 8 months ago

In multiplexing mode, tsh db config does work, as long there is nothing in between tsh and Proxy, as Proxy can detect Postgres protocol by peeking the package headers:

https://github.com/gravitational/teleport/blob/875e9337e00cc332a8e786612aaff2566b128858/lib/multiplexer/multiplexer.go#L805-L810

Different story when there is something sits in between. The middleman must understand Postgres protocol to extract TLS information.