Question on roadmap for not needing a public gateway

Hi guys!

Great work on launching this product. Overall I am a big fan of the work that you do.

I was watching: https://learn.hashicorp.com/tutorials/boundary/getting-started-intro?in=boundary/getting-started

And when going through the architecture I was expecting something along the lines of not requiring a gateway in the private network.

Ie the worker would be in the target network but when a user wants to get in then the controller asks the worker to initiate the connection through an external public bridge.

      Internet     |       VPC

User --> Bridge  <---  Worker.  ---> Target system
    
     --> Ctrl.  <----

This way we would not have to expose the VPC to the internet through a public address and adding access to new system doesn’t require exposing to the internet, just requires outbound network access from worker to bridger.

Anyway probably something you already thought about and that’s maybe over-complicated for a v0. Would be curious if that’s on your roadmap or if the cost of building this is too high vs benefits.

Thank you!

Thanks for the question @callicles!

The gateway in this example exists to allow IP packet routing from the client to the controller and worker. A good diagram that describes this setup is in our reference architecture.

The client connects to a target directly through a worker, without going through the controller. This allows us to scale both sets of the architecture independently but also means the controllers and workers don’t have to be on the same network (though they do need a route between one another).

However, you’re correct, the client does need access to both controller and worker to make this all possible. Given that connection is protected by AuthN/Z, and given sane networking controls (IPTables, security groups), this can be done safely.

Let me know if this answers the question!