boundary
boundary copied to clipboard
hashicorp
Target-to-Worker connections
Is your feature request related to a problem? Please describe. Reaching targets that are in environments where a worker can't be deployed, or the target refuses all inbound connections (even SSH) and uses a reverse tunnel to allow connection.
Describe the solution you'd like Either the ability to connect to other client machines as a valid target or to configure target hosts to connect to the worker (instead of worker to target).
Explain any additional use-cases A very specific example is a host managed by a vendor that is deployed to a customer network. In order to manage the device the vendor must be able to connect to the host, but customer networks can change and tend to block inbound connections, especially if the host is placed behind a DMZ.
Thanks for this point of feedback @jrauen. Sounds like there's two asks here,
- As a workaround, can client machines be a valid target? Yes, this is already supported. The client machine would need to be reachable by a Boundary worker. You would just add the client machine(s) as a host within a host set and create a target that grants access to that host.
- Does Boundary support reverse tunnels between targets and workers? Not currently. Reverse tunnels imply having an on-target agent for configuring the target to initiate the reverse tunnel at a known worker location. Boundary does not currently support target agents, so this is not yet possible. However, we are actively considering solutions to address locked-down target scenarios like this one.
And of course, as an additional workaround you could configure your target and/or firewall out-of-band to accept inbound connections only from Boundary workers (assuming that doesn't violate a security constraint).
So for the first item that only serves as a workaround if the host can connect to the worker instead of the worker to the host, which is essentially the ask in item two. Having the capacity for client-to-client connection simplifies the requirements for an on-target agent since the client would act as one, but it would still be dependent on the host client establishing a tunnel to the worker that can be utilized by the user client. Good to hear that these scenarios are being worked though.
Reverse tunnels imply having an on-target agent for configuring the target to initiate the reverse tunnel at a known worker location.
reverse proxy a http protocal seems need no agent on targets, and this scenario is really common.
This would require a host on the network that can receive inbound. The example use case is for reaching hosts in networks outside of your control, in which case you can't rely on inbound connections.
To add another "user story", we also have a use-case similar to the described "vendor device on client networks", but our case it is in an IoT setting. Our devices are deployed either with 4G connectivity or on some partner network over which we have no control. Since we have to assume we're exposed directly to the hostile internet, we do not allow any incoming connections. Currently we dial home and open a tunnel-within-the-tunnel (basically, ssh -N -R <some-port>:localhost:22 controlserver.domain.tld, so we can run ssh -p <some-port> localhost on the control server).
Does Boundary want to fill a role here? We'd be fine with running an agent on the device (it's decently powerful x86 hardware), but I understand this might be outside the problem space you are interested in solving.
Thanks for the additional scenario, @carlpett, and thanks for the further clarification @jrauen. While enabling target initiated connections to workers is not on our 6 month roadmap, it continues to be raised by a number of our users. Longterm, this is something in our vision for Boundary but we will need to continue investigating and rationalizing this vs other priorities before we can give a timeline. Stay tuned!
We'll keep this issue open for any additional interested users to share their scenarios.
Yeah, you definitely need to implement this feature as soon as possible to open a market of IoT/edge computing devices. Many companies sell applets and boundary may be very good solution for management of hardware that installed on customer side. In that way your solution can be a good alternative to Microsoft azure IoT hub. Please make configuration option for auto discovery that can be implemented as follows: boundary agent has generic access token, on fresh install agent makes API call to register itself, this request appears on boundary server and you choosing how to register this device from dashboard or reject a request, in that way it's very easy to prepare main template distribution and register each device later even when shipped to a client. Also you can grab some ideas from IoT hub. From my point of view it looks very strange that this feature is not on your 6 month roadmap.
Any progress on this? Boundary great product, but without ability to use in the behind the firewall scenarios it can be used probably in 10% scenarios. Most security scanners and audits disallow opening ports to the public and there is little sense to keep boundary installed on each edge location. We end up with same bastion scenario in such case, but now with boundary.
+1 This capability is essential for edge/field/IOT environments where there is little control to no control of the network perimeter or a network perimeter may not exist.
+1 We have currently deployed more than +100 IOT devices on ethernet cable and as a backup 4G. It would be great to have an agent similar as TeamViewer.
Thanks for the additional scenario, @carlpett, and thanks for the further clarification @jrauen. While enabling target initiated connections to workers is not on our 6 month roadmap, it continues to be raised by a number of our users. Longterm, this is something in our vision for Boundary but we will need to continue investigating and rationalizing this vs other priorities before we can give a timeline. Stay tuned!
We'll keep this issue open for any additional interested users to share their scenarios.
Been about two years since this comment was made. This is still a very important use case. Has it shown up anywhere on the roadmap?
Hi @badarsebard, we will be implementing a feature called Multi-Hop that allows Boundary workers to reverse proxy to other workers, so that there won't be any need for inbound access on private networks. This will be coming out relatively soon and you can find more information in this Hashiconf talk: https://www.youtube.com/watch?v=k7X8s6ib3YI
Edit: Multi-Hop will only be available on HCP Boundary
This seems like a step in the right direction. There is something in the presentation video that isn't clear, though. Is bi-directional communication needed between each worker/hop? If so, then this feature only addresses use cases where there is no direct connectivity between a worker and controller/client, but still requires an inbound connection to the final worker in the chain. This issue discusses the need for reaching workers where there is no inbound traffic allowed.
Just want to clarify one thing first: as we develop Boundary as a commercial product, certain features will only be available through HCP Boundary (and not open source Boundary), Multi-Hop being one of them.
To answer your question, a final worker (that communicates with the host) only requires outbound connections to a more readily available "public" worker. There will be no inbound traffic requirement to final workers or workers in hidden/private networks.
Excellent, thank you for the clarification. In this case multihop will satisfy the private/no access network use case that I originally brought up (@jrauen is my former user account).
Running a full worker on IoT/edge devices is not always possible, but I did see in the above conference talk there is consideration to build an agent in the future. I'd suggest closing this issue out with the upcoming MH feature since it addresses the core reverse tunnel/proxy issue and anyone who has a use case for IoT should open a separate issue and link back to this one.