Technically both are correct: it depends on your environment and access requirements.
The controller and worker can live in a private subnet, but it means that public clients won’t be able to access it. In the reference architecture, the AWS example uses all public subnets to make it “just work”.
That being said, I can certainly see situations where you might want an all private deployment: an intranet within a corporate campus for example, or a restricted network that is gated by another means.
For most folks using Boundary to gate access to a private network in a cloud environment however, having everything in a public network is most likely what is desired.
Good catch on the discrepancy in that blog post by the way, I’ll get that updated.
Thanks for your comment! At first, I thought that the controllers should reside in private subnet, to allow the workers in public subnet to reach instances or DB inside private subnet. I guess I’ve misunderstood the product. I’m currently doing PoC on Boundary, and could you provide a link where I can straighten myself?
Sure. I think the point of confusion here is this:
At first, I thought that the controllers should reside in private subnet, to allow the workers in public subnet to reach instances or DB inside private subnet.
Controllers and workers have no relation to each other in terms of connectivity by the client. The client needs to be able to access the controller to get authorization to connect to the endpoint; the client needs to be able to access the worker to actually make that connection. If the client is on the public Internet, the controller and worker both need to as well. If the client is on some private network, the controller and worker can both be on the private network too.
The key is that the worker can be straddling the destination network (which is not necessarily the same as the “private network” in the paragraph above) and the network the client is on. So a client can gain access from a private network to a subnet it might normally not have access to. Or it can gain access from a public network to the private side.
Thanks Jeff!
But I am still confused. Let’s say that both controllers and workers reside in public subnet. There are instances which I want to gain access in private subnet. As controllers and workers are both in public subnet, I understand that worker can easily reach the controller. However, how does the controller know the target instances inside the private subnet? (As I think we never told the controller the instances inside the private subnet, or a way to go into the private subnet)
As I think we never told the controller the instances inside the private subnet
There’s your issue If you haven’t gone through some of the getting started docs you may not have realized that you need to register your hosts with the system. This can be done manually, or with Terraform, or eventually via dynamic host catalogs as we build those in. The hosts contain connection information (e.g. their network address). When the client connects to the worker, it is then up to the worker to be able to make a successful connection to that end host. Neither the controller nor client need to have a direct connection.
If you haven’t gone through some of the getting started docs you may not have realized that you need to register your hosts with the system. This can be done manually, or with Terraform, or eventually via dynamic host catalogs as we build those in. The hosts contain connection information (e.g. their network address). When the client connects to the worker, it is then up to the worker to be able to make a successful connection to that end host. Neither the controller nor client need to have a direct connection.