4 ms·

What exactly is the security benefit of a reverse tunnel, in comparison to just listening on a port? Usually DB servers are "always on" and always accept conne

What exactly is the security benefit of a reverse tunnel, in comparison to just listening on a port? Usually DB servers are "always on" and always accept connections, so the reverse tunnel also needs to be always up. Regarding row-level security: that sounds quite awesome, but in the form it's described in the article, very limited in the number of use cases. Quite often you have a web app that talks to the DB and that uses a service account. So as with, with row-level security you can just allow or disallow things to the service account, not to the user logged into the web application. Is there a way to drop from the service account into a less-privileged role inside a transaction or so?

old-gregg 6y ago
Disclaimer: I work at Teleport (but I am not the author of the article). This work was done because the Teleport users who used it for SSH kept asking for the same access for their databases. The reasoning goes like: 1. Setting up a single proxy gives you the same benefits for N databases as they come online. No need to manage additional endpoints (public IPs, ports, etc). 2. You have the same centralized place to manage auth/authz for all users. 3. This allows to connect to databases on the edge, where there isn't an opportunity to have a permanent public IP and locations frequently go online/offline. 4. Finally, it's nice to have unified visibility into what's available (for users) and centralized logging/audit for the security team. As always, all of this is possible with other tools. The world of open source is vast and full of options, but we were hoping to make it simpler, with less configuration and moving parts.
hobs 6y ago
I know in SQL Server a lot of products use the CONTEXT_INFO function for this, basically store some variable per connection and change it for context switching/row level security. Obviously you need to trust the service account enough to do that.

old-gregg 6y ago

Disclaimer: I work at Teleport (but I am not the author of the article). This work was done because the Teleport users who used it for SSH kept asking for the same access for their databases. The reasoning goes like: 1. Setting up a single proxy gives you the same benefits for N databases as they come online. No need to manage additional endpoints (public IPs, ports, etc). 2. You have the same centralized place to manage auth/authz for all users. 3. This allows to connect to databases on the edge, where there isn't an opportunity to have a permanent public IP and locations frequently go online/offline. 4. Finally, it's nice to have unified visibility into what's available (for users) and centralized logging/audit for the security team. As always, all of this is possible with other tools. The world of open source is vast and full of options, but we were hoping to make it simpler, with less configuration and moving parts.

hobs 6y ago

I know in SQL Server a lot of products use the CONTEXT_INFO function for this, basically store some variable per connection and change it for context switching/row level security. Obviously you need to trust the service account enough to do that.