Mutual TLS target

Boundary
1

Hi,

I am setting up a cluster with Vault, Consul and Nomad all with MTLS enabled. Also the idea is that the services running on Consul will be in a service mesh so MTLS there as well.

My question now, is it currently possible with a Boundary OSS setup to connect to those targets?

Thanks

2

If your Boundary servers are also part of the Mesh, I don’t see why not.
I don’t think it supports mTLS out-of-the-box though so you probably need to use a sidecar or something similar.

3

How does the Boundary servers being part of the Service Mesh enable a connection through the Boundary worker to the Nomad Server? But for all connections I would need to create the correct mtls certificate with credential brokers?

4

Boundary servers include controllers and workers

5

Why? If the worker can access the target(s), the client connection would just be tunneled via the worker. The worker would need to be exposed in any case, to allow clients to connect to it

6

Isn’t it supposed to be two separate processes with separate concerns?

7

With a client setup like this would undermine the idea of access on demand and just be a VPN? If I open a connection to a target in Zero Trust network only this target should be reachable with all the required secrets
Thats why I thought about credential broker in Boundary OSS

8

That’s certainly a use case. Not the way Boundary is intended to be used in my opinion.

Boundary worker is acting as the PEP in a Zero Trust network architecture. Through its mutually authenticated connection to the PDP (the Boundary controller) it knows everything it needs to know in order to authorize or deny access to a target.

Why would you add yet another layer of policy enforcement in this case?

Ultimately, you’re shifting the trust domain from the Mesh to Boundary itself.

9

They are, I just mean both of them need to be part of the Mesh (or at least workers need to be able to reach the cluster port of the controllers)

10

I would be interested to hear a Boundary marketing person or engineer telling their perspective about this. With the dynamic secrets part of Boundary I would be surprised that the Boundary worker should have default access to all targets in the network. From reading the website and documentation I was under the impression that after authentication the controller would create all required secrets to reach a specific target, this includes the mtls certificate. But the last step is what I am unsure about how to achieve with the OSS version from Boundary

11

@PPacent @omkensey

For your appreciation

12

Thank you @macmiranda

13

We do want to support mutual TLS not as a target type but as a credential type/purpose that can be used when making a connection to the endpoint/host defined in any target type. We just haven’t gotten to it yet :slight_smile:

1 Like
14

Chiming in here – as Jeff says, the Boundary team has this pinging around in their heads, but there’s a lot involved in making the user experience for something like “generate mTLS client certs on demand and use them to authenticate to a secure endpoint” smooth, without ruining the security of the connection in the process.

Just to go over a few options in the present day:

  • Boundary workers don’t need access to all targets – but if you have workers that can only access certain targets, you do need to use worker filters to make sure Boundary knows to only send clients to them to try to connect to the targets reachable from that worker. For example if I have a worker in each of three AWS VPCs, I might tag those workers like this in their config files:

    tags {
  cloud = "aws"
  location = [some identifier for which VPC that worker is in]
}

    Then when I define a target in a specific VPC, I define an egress_worker_filter on that target something like so:

    egress_worker_filter = '"/tags/cloud" == "aws" and "/tags/location" == "[one of the VPC identifiers]"'

    That way I not only ensure that only the set of appropriately tagged workers will access that target, I can also lock down that worker’s access so that the worker itself can’t provide access to other parts of the network even if somebody subverted the worker instance somehow.

  • For mTLS, as @macmiranda mentioned, you can use Consul to implement service mesh for your network. Then, if you connect one interface of a Boundary worker to the service mesh and clients can also reach the worker from outside, you can use internal mesh service addresses as Boundary target hosts. There are some advantages to doing so:

    • You can use Boundary’s roles and grants to limit access by users, and you can use Consul intentions to add limits on what the Boundary workers themselves have access to, just like I mentioned in the example above. This is a big advantage if, for example, you need to just slam the door on a worker’s access to an entire area of your network for some reason (e.g. a worker instance’s OS was not properly secured and somebody subverted it and is using it to scan your network – you can just delete the Consul intentions that grant that worker access to things and immediately everything in progress from that worker, even stuff not going through Boundary, hits a wall).
    • You also now have transport security via the mesh’s encryption even for targets that don’t implement it themselves – for example a Postgres database that nobody’s bothered to set up TLS for. This means that traffic is now secure from packet-sniffing elsewhere on the network, which it might not be otherwise.
    • For services in a service mesh, you can set Consul up so that they only listen on localhost and Consul proxies incoming connections to them. Now things on other hosts can’t even scan them or connect to them without going through the service mesh – and you control that, and what’s allowed to happen on it. And with your Boundary worker in the mesh, you can still grant identity-based access from outside, with the ability to limit that access to only specific humans, by using Boundary RBAC.
    • Consul handles the mTLS part of things automatically for you – Boundary doesn’t even have to know any of that exists.
    • You can implement all of the above as a repeatable cloud-agnostic pattern.
1 Like
15

Thank you @jeff and @omkensey for this answer, exactly what I was looking for.
So now I know what is to come and what is best to do now

Just one more question remains in this context for me.

With the service mesh setup, can I include Nomad, Vault and the Consul server cluster as well, to connect to them through the service mesh?

1 Like