Our team is also at a stage where we would like to proactively associate a shared/sensitive policy to multiple jobs that may not even exist yet. What follows is what I tried to get working before I found this topic of @vikas.saroha…
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>
I can think of 2 ways that this could work intuitively, but I assume that would need to be feature requested?
Option 1: Defining it in the policy
Something like…
namespace "sensitive" {
variables {
path "*" {
capabilities = ["read"]
# list the jobs that have access to the variables in this path and namespace
jobs = ["*", "ARealJobThatExists"]
# or maybe the jobs are in a different namespace
jobs = ["*@default", "ARealJobThatExists@default"]
# or maybe multiple job blocks (like having multiple path blocks)
job "*" {
namespace = "default"
}
job "ARealJobThatExists" {
namespace = "default"
}
}
path "azure/*" {
capabilities = ["read"]
}
}
}
Option 2: Using a wildcard in the nomad acl policy apply command
Using a wildcard for the -job argument as per the examples above that only need to be executed once:
$ nomad acl policy apply -description "Proactive sensitive policy" -namespace default -job "*" sensitive /path/to/sensitive.policy.hcl