Shouldn't controller instances reside in private subnet?

The github example and also the boundary official website shows the architecture below, having both controller and worker instances in public subnet.

However, according to the https://medium.com/hashicorp-engineering/hashicorp-boundary-make-sure-your-human-to-machine-access-is-secure-68718674c22c , the hashicorp medium, the controller instances reside in private subnet. This may seem to confuse some people, including me. I believe controllers residing in private subnet seems to be correct. Any thoughts on this issue ?

Not speaking for whoever wrote the docs (I was confused too) but in testing I’ve found that the key is “publicly available”. So

You can expose your controllers via AWS ENI/public-interface
-or-
Use an ALB and not allow direct access.

I suspect that workers need to have an ENI since the client is given a specific worker to connect to and that is what the diagram shows.

1 Like

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.

1 Like

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?

@jeff - any input on this thread?

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 :smiley: 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.