Boundary will indeed give you a bearer token after authentication to present to take further actions in its API. So you'd authenticate to Boundary, get a bearer token, and use that to make one or more requests to connect to infrastructure or services. That bit is pretty much in line with most clouds, platforms, services, etc.
As for complexity, while Boundary overall is by no means a couple hundred lines, I will simply say that the vast majority of code (nearly the entire API) is related to user and resource management...how users are defined and authenticated, how infrastructure and services are described for access, RBAC, etc. The actual networking code performing the secure proxying is quite minimal because at least for the TCP tunnel it's more or less specifying the acceptable TLS parameters for that session and from there you're mostly in `io.Copy` land... it probably works out to a couple hundred lines :-D
What you're doing in Fly looks super cool and the stuff you're doing on gVisor (including the user-mode Wireguard stuff) is super cool too! Thanks for writing it up. And it sounds like the two solutions are more complementary than competing, so maybe at some point in the future you'll find that Boundary has a niche to fill in your setup as well!
TCP targets (the only kind currently in Boundary) actually work with _any_ TCP connection. The `boundary connect <subcommand>` bits are just some CLI syntactic sugar around the main `boundary connect` command -- which works all by itself! -- that fill in IP/port and other information for various clients. (This has been an unfortunate bit of confusion for many people trying Boundary out. We'll take another look at how we can make this more obvious in our getting started/learn docs.)
It's all TCP though. Eventually we'll do more interesting things with specific protocol types.
We don't have something natively, but you can control the address via BOUNDARY_ADDR env var or the -addr flag per-call, and you can use -token-name with the CLI to switch between named tokens, which can be sourced from different accounts. Together it'd be pretty easy to write a shell alias to do what you're looking for.
In an immediate sense you could have targets point to services handled by Connect, so you'd have client -> Boundary worker -> local Connect entrypoint -> end service.
We'll be looking more closely at other integration possibilities going forward!
By "direct network access" we mean between the client and the end host. The Boundary worker node (which proxies traffic) would need to be able to make a network connection to the end host, and the client in turn would need to be able to make a network connection to the worker node.
This indirection provides a way to keep your public and private (or even private and private) networks distinct to remove "being on the same network" as a sufficient credential for access. At the same time, it ensures that the traffic is only proxied if that particular session is authenticated.
I can see how that works for an internal network. How does this work for SaaS solutions that would normally be directly on the internet? Would they have to be "shielded" to be on a private network and somehow be "Boundary enabled"?
And could this be done in a way that is completely transparent to the user (without them having to start a connection to the worker first, and then make a connection to the desired service)?
Generally speaking this is designed for accessing your own systems, not the systems of a third party being consumed as a SaaS. That said, any such provider that allows you to restrict the set of IPs allowed to make calls to the service would operate in a Boundary-friendly mode.
It would be interesting if the networking model for the end targets could also be inverted, so that an agent (or something) on the end target could make an outbound connection to establish a reverse tunnel to the proxy that user connections could then be sent over.
The use case I'm thinking of is for IoT or robotics, where you have devices you want to manage being deployed into remote networks that you don't have much control over. It's really helpful in this situation if devices make outbound connections only, so that network operators don't have to configure their firewalls to port forward or set up a VPN.
It seems like using WireGuard on the "end target" to automatically connect to (WireGuard on) the proxy would be an easy workaround.
I did basically the same thing years ago for remote console devices deployed inside various customer networks where I had little or no control over the network. At that time, I used OpenVPN to automatically connect back to our "VPN servers" -- providing access to the device even if it was behind two or three layers of NAT (which, unfortunately, wasn't uncommon!).
CloudFlare Access allows this, using the cloudflared daemon, which acts as a reverse proxy. It essentially means the endpoint can be closed off to incoming connections from the internet, and you don't need to maintain various firewall whitelist (and hope they don't go out of sync)
Is something like this on the roadmap for Boundary?
Without committing to any specifics, I'll say that we are very aware of use-cases where a daemon on the end host can provide enhanced benefits.
As you can imagine we did quite a bit of research with our existing users/customers while working on the design of Boundary. One thing we heard almost universally was "please don't require us to install another agent on our boxes". So we decided to focus initially on transparent use cases that only require running additional nodes (Boundary controller/worker) without requiring additional software to be installed/secured/maintained on your end hosts.
> the endpoint can be closed off to incoming connections from the internet, and you don't need to maintain various firewall whitelist
If you think about this a bit differently, a Boundary worker is also acting as a reverse proxy gating access to your non-public network resources. You can definitely use Boundary right now to take resources you have on the public Internet, put them in a private-only subnet or security group, and then use a Boundary worker to gate access. It's simply a reverse proxy running on a different host rather than one running on the end host. You wouldn't _need_ to add a firewall to ensure that only Boundary workers can make incoming calls to the end hosts, it's simply defense in depth.
As you say, it's a big question. But one way to start is by integrating this _within your VPN_ such that network access + credentials alone are not enough. With Boundary you could do this by setting up firewalls on the end hosts to only allow ingress from Boundary worker nodes.
Eventually you can migrate towards Boundary nodes (or similar technologies) being the public ingress instead of a VPN endpoint.
(Edit: clarified that I meant firewalls on the end hosts, not on the VPN or elsewhere in the network.)
You didn't. Mirroring in this case refers to using git --mirror.
You're assuming it works like a traditional file system or block level mirror, but it doesn't. Corruption would in most cases have been caught. The weak (and accidental) link was relying on the server to give us a proper accounting of the current valid repositories.
However, once authorized, the actual session uses a TLS stack generated for that individual session to establish a secure tunnel. It's explained at https://www.boundaryproject.io/docs/concepts/security/connec... if you're interested.
As for complexity, while Boundary overall is by no means a couple hundred lines, I will simply say that the vast majority of code (nearly the entire API) is related to user and resource management...how users are defined and authenticated, how infrastructure and services are described for access, RBAC, etc. The actual networking code performing the secure proxying is quite minimal because at least for the TCP tunnel it's more or less specifying the acceptable TLS parameters for that session and from there you're mostly in `io.Copy` land... it probably works out to a couple hundred lines :-D
What you're doing in Fly looks super cool and the stuff you're doing on gVisor (including the user-mode Wireguard stuff) is super cool too! Thanks for writing it up. And it sounds like the two solutions are more complementary than competing, so maybe at some point in the future you'll find that Boundary has a niche to fill in your setup as well!