job specification consul block enhancement

[MorphBonehunter]

Proposal

Background (to whom it may concern 😄)

After review my nomad/consul/vault ACLs on the weekend, I lernend on the hard way that I need an consul {} block in my job specs if I want to use the template block (my default agent token was waaaayyy to permissive so I missed that change).
Problem here was that the second example in the consul-token-for-templates suggest you can leave out the consul and identity blocks when using consul.task_identity in the server which doesn't work (and is wrong?) but the Workload identities in the identity block stated that template blocks are not provided with default identities.

Real Proposal

After inserting the consul {} block to my job specs for using the template blocks, the task has always CONSUL_TOKEN in the env the token saved to secrets/consul_token.
This isn't always desired and should be configurable like in the vault block:

consul {
  env = false
  disable_file = true
}

Use-cases

If the Consul Token is only needed for the templating and the task themself doesn't need it, this could be seen as an security enhancement for example in case of the identity could read parts of the K/V store.
Also there are cases where the Application inside react on the Environment and preferred it over an for example configured file with another key so you have to unset the env first.

Attempted Solutions

I did not finde an included way to disable the environment or File generation.

[mismithhisler]

@MorphBonehunter You're absolutely right about the docs not being correct. We're going to review these workload identity docs and make sure they align with the desired behavior of Nomad. I'll link to this issue in that PR and try to get it up today.

As for the general idea of generating a token for the template that isn't shared with the task, I think that's also a valid feature request. We'll probably want to think this through a bit just because at first glance it seems odd to generate a task token but then not give it to the task? Maybe that's not as weird as I think. We used to have separate identities for templates, but removed them in favor of using the task identities.

While the docs updates I can do immediately, I'm going to mark the feature request bit of this for roadmapping so we can get it reviewed by the team as a whole.

[MorphBonehunter]

Thank you @mismithhisler for your response...and thanks for treating the introduction as bug report 😄

In my eyes the point is, that you have to use the task tokens if you use templating with the side effect that the task itself has access to the token.
As this is the case for both, consul and vault, only the vault block allows disabling this behavior to enhance security.
I'm aware that the K/V store on consul should not be considered confidential but it could be better to not expose information's to tasks which doesn't use them. Maybe an malicious actor which has access to the application in the task could use this to get some insights of the environment or something while accessing the K/V as an constructed scenario.