Apply a workload identity to all jobs in a namespace

[msherman13]

Proposal

Currently, each workload gets an implicit acl policy or an acl policy which was explicitly associated with the job/group/task. The implicit identity allows jobs to list services from any namespace, which can be a security issue depending on the use case. I propose to add an option to change the implicit workload acl policy on a per-namespace basis.

Use-cases

If namespaces are being used to segment teams within the cluster, seeing other teams’ jobs can be a security issue (it is in my case).

Attempted Solutions

One workaround is to apply acl policies to specific jobs. However, nothing is preventing users from creating new jobs which use the implicit policy.

[msherman13]

@jrasell your comment here seems relevant: #17245 (review)

[lgfa29]

Hi @msherman13 👋

So I understand the problem more clearly, what you're proposing is way to configure the default ACL policy for task workload identities to only be able to access services in the same namespace?

[msherman13]

@lgfa29 That may be necessary to achieve what I'm describing, but maybe besides the point. We want to be able to create a "Workload Associated ACL Policy" (as described here: https://developer.hashicorp.com/nomad/docs/concepts/workload-identity) which is automatically applied to all jobs within a namespace. Currently, we can associate ACL policies to workloads by applying acl policies with "-job", "-group", and "-task" flags. I propose to also add a "-namespace" flag which would create a namespace-wide acl workload policy.

My goal is that jobs would only be able to see services (i.e. GET/v1/services) from their own namespace. Since the default policy permits listing services from any namespace, that maybe would need a change as well since I think access from both the default policy as well as my proposed namespace policy would be additive (can you confirm that is the case?)

[lgfa29]

Oh I see, thanks!

One of the challenges is that I would imagine the default policy configuration would require some kind of templating as some may want to have policies that restrict access to some resource based on the job, group, or task name for example.

We would have to think about the exact behaviour we want, so I can't say right now if they would additive or not.

I have placed this feature request for further triage and roadmapping.

Thanks for the suggestion!

[tgross]

Doing a little tidying up and this issue is a duplicate of #17181. I'm going to close this one out and make sure the other gets properly marked for roadmapping.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.