How’s this work with things that aren’t websites? Do you have to throw a proxy in front of e.g., your database server that keeps track of which IPs have already authenticated over the web?
* You used a modified client or client proxy (this was done for e.g. SSH)
* You used a remote-desktop protocol to remote into a machine with direct network access to the service
* The service got a wholesale exemption and was allowed through the firewall with ordinary IP ACLs
(descending order of impressiveness wrt the BeyondCorp philosophy and whitepaper)
Some of this is discussed in the "Non-HTTP Protocols" section of this paper: https://www.usenix.org/system/files/login/articles/login_win...
some protocols are udp and latency sensitive, which doesn't work well enough tunneled
In some ways this is a poor man's VPN server, but it can be smarter: with protocol support, you can combine the identity of the connected developer with application-level data (e.g. this is an INSERT statement) to make AuthZ decisions.
At Transcend, we use a bastion host (like others have mentioned). The key difference that we do that I don't think has been covered is that our bastion only makes outgoing connections, and has no open ports to the world.
Using the AWS SSM managed service, we can create bastions that have no ingress at all.
I talk through some different approaches in a codelab over here: https://codelabs.transcend.io/codelabs/aws-ssh-ssm-rds/index...