Access control for Nomad clients

Hello everyone,

My team and I are trying to apply authorization rules to Nomad clients, example scenario:

Given clients:

  • env1: client1, client2.
  • env2: client3.

Given jobs:

  • env1: jobA, jobB, jobC.
  • env2: jobD.

Expected behavior:

  • client1 and client2should only be able to accessjobA, jobB, jobC`.
  • client3 should only be able to access jobD.
  • Someone who has access to the configuration of a Nomad client only shouldn’t be able to assign it to another environment (eg. I should not be able to assign client1 to env2 without admin permissions to the Nomad servers).

We already have mTLS in place and we were looking into Namespaces, ACLs and Sentinel policies as well, but we couldn’t find a way to solve (other than security by obscurity - using secrets as cluster names).

Our current idea is to add (optional) capability for Nomad to authorize clients via ACLs as well (not just API calls): that way we can generate an ACL token for a Nomad client, only having access to a given namespace (and we would create a namespace for each environment).

Are we missing something and is there a better way to do this?
Thank you in advance,
Szabolcs

Hi Szabolcs!

Were you able to find a solution to this?

We are facing similar issues as we’re looking to add potentially untrusted clients to our Nomad cluster and want to be able to limit what they can access.

Currently, we haven’t come up with a better idea than to write our own custom proxy that will sit between the untrusted clients and the servers, but it seems like quite a lot of work.

Hi @oloff!

Nothing easy, unfortunately. We decided to add authorization of clients via ACLs (ACLs were released in the open-source edition as well not that long ago) - we had a working POC but the priority of this track wasn’t high enough for us so we will only pick it up later (not sure if upstreaming these changes is welcome or not, we might need to go with a custom build).

Best regards,
Szabolcs