Allow setting of AccessorID for ACL Token

[zemm]

Proposal

Add optional parameter AccessorID for setting the accessor while creating a new ACL token. If AccessorID is not given, it would be generated, like it does now.

This would add a deterministic way for CM tools to manage a token in an idempotent and stateless manner. Currently Nomad allows multiple tokens to have a same name, so the name field cannot reliably be used as an handle on recurring runs. The current AccessorID cannot be used as a handle without caching, since as it's always generated, it cannot be known beforehand.

This has been added to Consul at 1.5 for seemingly similar reasons.

Use-cases

I wrote two Ansible modules for internal use to manage Consul's and Nomad's ACL tokens.

For Consul, I could define an api like so:

- state: present
  accessor_id: <deterministically generated or from some storage>
  description: foobar
  policies: [...]
  roles: [...]

This makes the management logic easy:

• If a token with given AccessorID exists
  • If state == absent, delete it
  • Else check that the desired state is correct, modify if needed
• Else
  • If the state is present, create a new token

Now with the current Nomad API, the only deterministic handle seems to be the name. But the name is not guaranteed to be unique.

- state: present
  name: foobar
  type: client
  policies: [...]

If multiple tokens with the given name exists, I cannot see a safe way to proceed. Even if there is one, the name is not complex enough, there could be a change it's not our token. Also, with Consul, I've already refined the description field multiple times to make it more clear to the user. With the current Nomad API, this name (which is the only user-friendly descriptive data) could be changed.

Attempted Solutions

Currently the only way I see is to use the Name, take care with naming, never change the name and fail immediately if there are more than one tokens with the same name.

The only another approach I see is to cache the accessor ID, but this makes things considerably more complex, and clearing the cache (which happens) would produce duplicate tokens, and the old ones would never be cleared. The cache would actually be partial master data.

[jrasell]

Hi @zemm and thanks for the detailed write-up. This seems like a sensible idea and is helped by the fact Consul has also implemented this change successfully. I'll mark this issue for roadmapping, although I can't give any estimate on when this would be worked on.

[zemm]

Great!

The Consul side also discussed and added the ability to set SecretID. Personally I don't need this, so I don't have an opinion on that. At least with Ansible I can have the secret, without storing or replicating any state outside of Nomad, as long as there is a deterministic handle (the accessor) for the token.

Meanwhile the workaround using the token name works, but is unsafe and feels wrong.

[mikenomitch]

Since this is an accepted idea and there is existing art in Consul, I am adding the help-wanted label. Unfortunately this isn't super high on the core team's To Do list but PRs welcome!

[ekristen]

Yes! Please allow setting of both accessor and secret ids by the user. I really need this feature. We are about to be running dozens of micro clusters of nomad for development and special projects and I need the ability to set a common set of tokens across them.