Feature: packaged client config+token delivery

[hazcod]

Is your feature request related to a problem? Please describe. We need to deliver access to our Boundary instance in a fast and easy way. Needing to install and run a boundary command is cumbersome for non-technical people. Ideally we should be able to automatically open a connect (tcp, http, ...) to a specific target based on the packaged token.

Describe the solution you'd like Delivery of a token which contains necessary client configuration.

Describe alternatives you've considered Having the boundary client installed and clicking through a complex web interface.

[malnick]

Thanks for posting this @hazcod and sorry for the tardy response.

I'll run this request by our product manager @PPacent but in the meantime, have you taken a look at our desktop client? We're hoping to build features into this tool to enable some of the workflows you've mentioned here (though still requires some use of the terminal).

[hazcod]

@malnick I must admit I'm quite new to boundary so I'm not too fond of using a thick client/cli to be able to access apps. Is the target audience solely technical people? (e.g. I compare this to e.g. Cloudflare Access) It's completely possible my use case does not map to boundary.

What I'm missing from the website is: where does boundary fit in and where doesn't it?

[covetocove]

@hazcod - this is an interesting suggestion! I sent you an email from your github profile if you'd like to chat with the team and talk through your requirements here.

And your point is well-taken on the website documentation on where Boundary fits in. Our goal is for Boundary to be a tool to manage multiple types of access use-cases - both technical users accessing infrastructure and non-technical typically accessing tcp/ip based targets. Given the project is still relatively early stages I think it's fair to say we're more mature for the former scenario - access management for technical users accessing infrastructure.

[hb9cwp]

Since boundary-ui made its appearance, I am asking myself if it could be built using WebAssembly (WA) in order for Web browsers as additional target platform, e.g. to load the client (WA code) as well as its configuration from a Boundary Worker for example, and then to run it native in the browser? A bit similar to a Progressive Web App (PWA) that uses aggressive caching, that can be started from the desktop by clicking an icon like an installed (fat) app? That would also solve the distribution and update problem to clients, which will always be fresh/evergreen.

[jefferai]

We do want to be able to launch sessions from a browser eventually but you can't do arbitrary TCP tunneling so it's somewhat limited. You can do websockets and tunnel over that (and in fact, we purposefully use websockets in our proxying so that we can tackle the browser case at some point), but then your client code still needs to live in the browser, which is quite limiting, and it places a lot of restrictions on how you handle TLS. If you look at what something like Apache Guacamole does, they had to reimplement every other protocol on top of a meta protocol to be able to interpret and forward some kind of display. The other option is to support protocols for which a good JS library exists.

I do want to point out that you can use boundary connect under the hood in ways that hide it from users. You can, for instance, set up an SSH ProxyCommand directive such that users think they're SSHing normally but instead it authorizes the session through Boundary.

[xingluw]

Closing as won't do since other roadmap items will solve this.