With Hashicorp's Nomad, I've followed the steps outlined in the Workload associated ACL policies section of the Accessing variables from tasks tutorial and I have it working.
Here is an example of the policy file named sensitive.policy.hcl
:
namespace "sensitive" {
variables {
path "*" {
capabilities = ["read"]
}
path "azure/*" {
capabilities = ["read"]
}
}
}
It works as expected when applying it to a real job:
$ nomad namespace apply -description "Namespace for sensitive variables" sensitive
$ nomad var put -namespace sensitive @../path/to/sensitive.nv.hcl
$ nomad acl policy apply -description "Sensitive policy" -namespace default -job ARealJobThatExists sensitive /path/to/sensitive.policy.hcl
and then use it in a template:
job "ARealJobThatExists" {
...
group "example" {
...
task "example" {
...
# Template to load sensitive properties into ENV VARs
template {
change_mode = "restart"
error_on_missing_key = true
destination = "${NOMAD_SECRETS_DIR}/.azure"
data = <<EOT
{{- with nomadVar "azure/properties@system" -}}
PROP1 = {{ .prop1 }}
PROP2 = {{ .prop2 }}
{{- end -}}
EOT
}
...
}
}
}
However, I would like to associate the same policy to multiple workloads (jobs) that don't yet exist. In other words, I want to proactively associate the policy to a wildcard of jobs so that the new jobs (created by coworkers) will automatically have read access to existing secrets. The coworkers can list the secrets/variables but not read them.
I tried the following, without success:
$ nomad acl policy apply -description "Proactive sensitive policy" -namespace default -job "*" sensitive /path/to/sensitive.policy.hcl
Inspecting the policy returns the following:
$ nomad acl policy info sensitive
Name = sensitive
Description = Proactive sensitive policy
CreateIndex = 12070
ModifyIndex = 12070
Associated Workload
Namespace = default
JobID = *
Group = <none>
Task = <none>
Is there a way to achieve this or should I put in a feature request?