the-maldridge
commented
2 years ago An additional bullet point here is that the inability to set a port for things to bind to from boundary-desktop makes this difficult to practically use for things that expect a fixed port number such as the CLI tools.
Is your feature request related to a problem? Please describe. When actually deploying boundary to end users it is often desirable to have it running as a service in the background to bring up certain "always on" tunnels that are needed to allow other components such as Vault to authenticate. This use case is effectively already solved by the existence of boundary-desktop's web front-end.
Describe the solution you'd like I want documentation and examples of how to run boundary with its web front-end locally. A concrete example showing a boundary daemon running in the background and using a web browser to open up tunnels on the local machine would be an ideal way to solve this ticket. For bonus points add a config item somewhere for the CLI to have a list of tunnels it brings up automatically once authenticated.
Describe alternatives you've considered I have considered hacking this together with a docker container and an uncontained boundary managed by shell scripts. The docker example is not cross platform due to the unique way that docker networking works on macs, and in general I'd like to reduce my and my team's usage of docker down to zero.
I'm part of the way there with writing a very large service script that understands how to drive boundary and get access to things, but its buggy and boundary is painfully slow I'm coming to realize (order 20s to complete basic actions related to individual targets). This script has become so complex though with locking and making sure that only one tunnel to a given target is running at any given time that its becoming difficult to track down the bugs in it.
Explain any additional use-cases VPNs are transparent, which is part of the reason they're so popular to deploy. If boundary is trying to prove that zero-trust and beyondcorp architectures are practical, its going to have to compete in the same game, and part of that is ease of use. The hoops that are required to jump through to make this work today are not a polished user experience and something that is difficult to sell developers on. Specifically having to use the electron app is something I've encountered significant and sustained pushback on, but it often seems to be the only way to reliably get tunnels to stay up.
Additional context Somewhat ironically the only reason I'm running boundary at all in this environment is because Nomad, Consul and Vault don't have the ability to auth themselves to existing beyoncorp solutions. It feels like I'm using the wrong tool for the job in standing up full transparent TCP tunnels point to point for that use case. I have additional use cases on the horizon for boundary that justify its use, but its painfully slow for establishing tunnels for CLI tools like the nomad CLI, even when making the tunnel persistent with unlimited connections. I'm not sure if there's just a serious performance bottleneck somewhere that I need to scale around or if this is the expected performance margin. Running as a daemon is my idea for how to hack around this, but ultimately it feels like its the wrong solution. Perhaps there's something I'm not seeing here?