Nomad client tokens with multiple Nomad policies based on LDAP groups

[shoeffner]

Is your feature request related to a problem?
In Nomad, we have one namespace and policies per namespace for each of our projects.
Each project has its own LDAP/AD group, and if a users needs access to a project, they get assigned to the corresponding LDAP group.

This works fine when creating Nomad client tokens using a management token: we combine all policies a user needs (https://learn.hashicorp.com/tutorials/nomad/access-control-tokens?in=nomad/access-control#generate-a-client-token).

However, when generating Nomad client tokens with Vault, we cannot dynamically pass the policies, as we have to create Nomad roles which map to Nomad policies in advance (and generate Vault policies in the LDAP plugin which grant read access to those Nomad roles).
This is somewhat analogous to the /auth/token/create and /auth/token/create/:role_name endpoints – the Nomad plugin only offers the latter as /nomad/creds/:nomad_role. (If I understand it correctly, this is by design, as Vault restricts access to the respective paths and performs no further checking after that – thus, whoever has access to /auth/token/create can potentially create a token for any roles.)

What we would love to have is a mechanism to create a Nomad client token which dynamically bundles all (Nomad) roles a user should have access to through their LDAP group membership.

Here is a rough sketch, as I otherwise get lost with all the different policies, roles and tokens quickly:

The user authenticates with Vault via AD, gets a Vault token with authorization based on the LDAP groups. Then they want to use that Vault token to request a Nomad client token. They want one for both projects so they do not have to exchange it too often, but since generating all Nomad role combinations doesn't scale for us, there is no such role.
With Nomad directly, however, it would be possible to issue such a token.

Describe the solution you'd like
What we would love to have is a mechanism to create a Nomad client token which dynamically bundles all (Nomad) roles a user should have access to through their LDAP group membership.
The favorite solution would be to have a single API endpoint a user could query with their Vault token to create a Nomad token.

(We know that Nomad 1.4 is supposed to have SSO, but we believe this problem is independent from the Authentication mechanism but rather with way Vault's role based access to Nomad works.)

It is clear that this is not exactly how Vault's role-based authorization system works, but in this case roles seem to be too inflexible (or at least too inconvenient from our users' perspective).

Describe alternatives you've considered
We considered the following possible solutions:

Patch the logical/nomad plugin
This would be our preferred solution if it is something Vault can and will provide.
Otherwise we'd have to try and patch it ourselves and build our custom Vault.
I briefly attempted this yesterday but the main hurdle is that I cannot filter the nomad roles for those a requesting client_token is authorized to access. If there is a way to do that, I am more than happy to learn about that and can offer that I/we implement a patch.

Custom Vault Plugin
Essentially the same as before, except it would be decoupled from Vault and thus easier to maintain if this is not something which should be part of (upstream) Vault.
However, has the same problem that I currently didn't find a way to filter the available nomad roles according to the client token authorization.

Don't use Vault
We could write our own "self-service" solution with its own Nomad management token and its own mappings from LDAP groups to Nomad policies to create and revoke Nomad client tokens. Potentially, it could use Vault for the LDAP authentication or at least for Authorization using the normal Token mechanism.
However, we want to avoid writing the whole auth service ourselves, as that always comes with way more security concerns than using an off-the-shelf solution such as Vault.

Auto-manage Vault roles
We can imagine to create Nomad roles as they are requested. Again, this would be an additionally service which would consume a Vault-Token, check its Vault policies, read out the authorized Nomad roles, collect the Nomad policies therein, and create a new unique Nomad role with those policies, unless that exists.
This solution is probably easier to reason about within Vault, but way more complex than the other three.

Explain any additional use-cases
We know no other use case right now, but being able to do Nomad authorization based on LDAP groups with the Vault integration to manage the tokens for us seems like a feature others would enjoy, too.

[shoeffner]

Since we finally were able to switch to OIDC, I can report that this issue can be resolved with Vault as an OIDC provider.
While it does not have much flexibility to configure scopes, it works with some caveats:

• Only a sparse set of useful properties is available for scopes and those are not really very dynamic: https://developer.hashicorp.com/vault/docs/concepts/oidc-provider#scopes
• the identity.groups prefix used in ACL policies is not available for the scopes, barring us from accessing, e.g., identity group metadata (when attempting to edit it, we get an error that "no groups are set", despite the fact that in the same code a couple lines above it looks like the groups must've been set to be able to access identity.entity.groups.names)
• we would like to, e.g., filter LDAP groups to only contain a specific subset (say, groups with a specific prefix or piece of metadata)
• metadata is a map of strings to strings, we were not able to, e.g., assign lists of strings as custom metadata

However, the general working gist is:

1. Create policies and/or roles in Nomad
2. Setup the LDAP secret engine
3. Configure Vault as an OIDC identity provider with a scope which includes the groups:

   resource "vault_identity_oidc_scope" "groups" {
     name        = "groups"
     description = "The groups scope provides the groups claim using Vault group membership"
     template    = <<-EOF
     {
         "groups": {{identity.entity.groups.names}}
     }
     EOF
   }

4. Use Vault as Nomad's OIDC provider and set up an acl_binding_rule which adds policies or roles based on the groups.

So while this issue is not resolved, using Vault as an OIDC provider circumvents it.