You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nomad vault integration with workload identity - Similar to how nomad variables use ACLs and workload identities to narrow down the variables access to particular job, we should do something similar with vault integration.
One idea is - we can create a parent (or nomad-prefixed) path in vault and can mount required secret backends on that path either like nomad-pki or nomad/kv or nomad/kv2 etc. Nomad will have the token to access any of these paths, but nomad will only insert the secrets in the template if the workload id matches the suffix as like nomad/kv2/:job/:group/:task. This might be similar to consul connect ca - where vault will store the certs, but consul will take care of injecting / managing required certs in the services mesh.
Use-cases
More security. The current vault integration uses a blanket policy implementation of token i.e any job can request all tokens (as allowed by the blanket policy) from vault (correct me if wrong). For example, job1 can access job2's secrets. So any rouge job can access the secrets of all jobs.
Attempted Solutions
Nomad variables is a pretty good solution but considering the unix philosophy, vault is the tool for secrets management and I would like to delegate that task to vault.
The text was updated successfully, but these errors were encountered:
Hi @blmhemu! We've got some work on the public roadmap around Workload Identity and Vault, currently tracked in #15617. The idea here is that rather than there being a separate secrets backend, we'd be using the existing JWT auth methods to access secrets based on policies set for those identities. I'm going to close this issue as a duplicate but link to it from there as a motivating use case. Thanks!
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.
Proposal
Nomad vault integration with workload identity - Similar to how nomad variables use ACLs and workload identities to narrow down the variables access to particular job, we should do something similar with vault integration.
One idea is - we can create a parent (or nomad-prefixed) path in vault and can mount required secret backends on that path either like
nomad-pki
ornomad/kv
ornomad/kv2
etc. Nomad will have the token to access any of these paths, but nomad will only insert the secrets in the template if the workload id matches the suffix as likenomad/kv2/:job/:group/:task
. This might be similar to consul connect ca - where vault will store the certs, but consul will take care of injecting / managing required certs in the services mesh.Use-cases
More security. The current vault integration uses a blanket policy implementation of token i.e any job can request all tokens (as allowed by the blanket policy) from vault (correct me if wrong). For example, job1 can access job2's secrets. So any rouge job can access the secrets of all jobs.
Attempted Solutions
Nomad variables is a pretty good solution but considering the unix philosophy, vault is the tool for secrets management and I would like to delegate that task to vault.
The text was updated successfully, but these errors were encountered: