Modify /etc/hosts to provide a simple UX for non technical users accessing https sites

[rileytg]

Is your feature request related to a problem? Please describe. My non technical users get scared with http://locahost:12345 in their browser. The http goes against everything they’ve been trained in security awareness (NEVER use http…). The localhost is just confusing, makes them think they’re accessing something on their computer, and the port being some random number entirely confounds them.

my db users just find it annoying to have to update their scripts and tools to use new port every time.

Describe the solution you'd like The solution described in this https://github.com/hashicorp/boundary/issues/844

That solution using connect with -host and curl options + editing /etc/hosts looks like something that could be added to boundary ui in an automated way.

My question is, is editing /etc/hosts something on the table? I don’t really know the implications of editing that file… i’ve done it but not sure if that was a bad idea.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

n/a

Explain any additional use-cases i can setup something like datagrip to one “url” that gets dynamically managed in boundary. so when i create a new session i don’t have to reconfigure my datagrip. especially if i’m using vault to automate creds…

Additional context I built and manage a product that provided exactly this kinda functionality using vault and dns for my team. we have been using in prod for over a year with ~100 users.

if this (managing local dns via /etc/hosts) is something that you’re open to, i’d like to start a pull for this.

[rileytg]

https://github.com/txn2/txeh

[springroll12]

I was about to create an issue for something extremely similar.

The use case I see is for services you access every day, but which are secured by boundary. For example, if you have a Vault server that you would prefer not to expose to the world, but also needs to be accessed by developers on a daily basis, it becomes a pain to log into boundary and copy urls around. Copying a url is generally fine for a service you use once-in-a-while, but extremely tiresome for services you need to access frequently.

The UX issue cannot be overstated in terms of driving adoption either. If you want non-technical users to adopt boundary, then access to a host must be reasonably seamless from the desktop client. Clicking "Connect" or "Authenticate" next to a host, having it re-set the domain in your /etc/hosts and navigating to a bookmarked url is a much simpler workflow.

The solution I came up with was very similar:

• Run a local dns server and assign static domains based on the boundary host name (e.g. boundary host: site-dev -> site-dev.boundary.local)
• Redirect these domains to the correct boundary proxy dynamically (e.g. localhost:56778 -> site-dev.boundary.local)
• Users can then always access the domain regardless of the boundary proxy port

I assume it will be easier to support multiple OS by running a local DNS server, but I admit I am not familiar with how DNS overrides work on Linux/MacOS/Windows. If it makes more sense to modify /etc/hosts or equivalent then that is the way it should be done.

[malnick]

Thanks for submitting this! The hosts file changes across platforms, making this a bit of a challenge because we support linux-like and window's distributions. That being said, owning our own DNS would be incredibly useful for other behaviors and workflows and it's been tossed around on occasion. This is a long way of saying this isn't on or off the table, but we don't have a clear path for it in our road map at this time.

A possible work around is to manage /etc/hosts on your end users machines through a script that your org maintains. I know it's not ideal, but if you're installing boundary on your users machines you could wrap up the logic to modify /etc/hosts in the same script that installs and configures boundary for your users.

[rileytg]

Quick note, this is what docker desktop did:

# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section

[rileytg]

docker desktop, a widely used desktop application in the devops space, modifies /etc/hosts without explicit consent. they also just wrap it up in some comments.

I'm currently experimenting with running a little reverse proxy. the /etc/hosts solution only removed localhost from the users perspective but still leaves ugly random ports around.

My team has also complained that bookmarking is a huge thing for their workflow, they are refusing to use boundary until i can answer that...

[rileytg]

i haven't done any experimenting yet but I think some kinda of dns solution will be needed to support host cert checking. will experiment with some servers with that enabled using vaults ssh signer backend.

[david-peters-aitch2o]

I have tried to use /etc/hosts and it relatively works ok but there are issues when you have to use OIDC or even google auth, say you want to use Boundary to get to a jenkins server which uses google auth, the redirect from google is unaware of the port you're on, the -L does work but not in this case

[jrhrmsll]

A proposal to made the access to HTTP targets more simple, https://medium.com/@jrhrmsll/access-to-boundary-http-targets-made-simple-6069dcb3aabe

[miriamssinger]

Hi @malnick any news regarding this issue? We're considering using Boundary in order to access services such as Kibana, grafana, etc. (hosted by us), and we need to understand how well Boundary works with web targets

[DrackThor]

+1 here, we would also very much like to see a solution here. Handling this manually is quite tedious, so an out of the box boundary solution would be amazing 😄

[elopsod]

+1 here, we would also very much like to see a solution here.