It is not a good idea to allow your BOSH/CredHub/Vault to be accessible on the public internet. Yes, they both require credentials and certificates to access, but there is just no good reason to expose them on the internet. So you will only deploy them into private networks.
Unfortunately, now you’ve made it hard for yourself to access them from the Internet.
Fortunately, you can make this problem almost invisible to yourself thru the wonders of SOCKS5 proxies and the ever handy ssh tool. In this article we’ll create a magical tunnel from your laptop into your private BOSH and its deployments thru a public jumpbox/bastion.
I’ll assume you have a minimum of two subnets: one publicly accessible via the Internet (called the DMZ, or Demilitarised Zone), and the other that is not (called the private subnet). I’ll assume your BOSH and all its deployments are in the private subnet.
The first step to using magical SOCKS5 tunnels is to run a jumpbox/bastion VM in the DMZ. You and your team will have SSH access to this jumpbox. If you’re running Pivotal Cloud Foundry then you can use your Ops Manager. If you don’t already have a jumpbox, or a wrestling with how to manage a long-lived jumpbox and its persistent data, allow me to point you to https://github.com/cppforlife/jumpbox-deployment.
Next, in a terminal window you run ssh with the -D and -N flags.
ssh -D 9999 allocates a socket to listen to port 9999 on your local machine. Connections to it are forwarded based on the SOCKS5 application protocol. In lieu of further explanation, I’ll resume using the terminology "magic tunnel".
The ssh -N flag allows you to run ssh without a command or terminal prompt.
For example, to open a SOCKS5 magic tunnel you might run:
ssh -N -D 9999 [email protected] -i path/to/jumpbox.pem
The final step is for your local applications to know how to use a SOCKS5 tunnel. Not all applications do. Fortunately bosh and credhub CLIs can use a SOCKS5 tunnel if they discover specific environment variables.
To configure bosh to connect to our magic tunnel on local port 9999:
export BOSH_ALL_PROXY=socks5://localhost:9999
To configure credhub to connect to our magic tunnel:
export CREDHUB_PROXY=socks5://localhost:9999
To configure the Vault CLI safe to connect to the magic tunnel:
export HTTPS_PROXY=socks5://localhost:9999
And you’re done.*
You can now target your BOSH director or any CredHub API with the IP address as if you had direct access from your local machine. The bosh and credhub CLIs will do all the work to use the magic tunnel to make it work.
*But wait…
All is not perfect. At the time of writing, bosh and credhub CLIs get quite cranky if $HTTPS_PROXY is also set. I’ve raised issues for both:
- https://github.com/cloudfoundry/bosh-cli/issues/401
- https://github.com/cloudfoundry-incubator/credhub-cli/issues/40
Thanks to James Hunt for guiding me to the Dinosaur Train magic tunnel image. May small children forever have fun TV to watch.
Spread the word
