policies for workload identity aren't merged

[tgross]

If you have a job example with task group web and task name httpd the allocation's workload identity will automatically be granted Read access to the secure variable path nomad/jobs/example/web/httpd (as well as nomad/jobs, nomad/jobs/example, and nomad/jobs/example/web. However, if you add an extra policy to get automatically associated to the job, only that policy is used. So for example, if I create the following policy at _:example/web/httpd (keeping in mind this name doesn't actually work, see #13995):

namespace "dev" {
    path   "*" {
      capabilities = ["list"]
    }
  }
}

Then I the task's WI can no longer Read nomad/jobs/example/web/httpd, only List it. Instead we need:

namespace "dev" {

  secure_variables {
    path   "nomad/jobs/example/web/httpd" {
      capabilities = ["list", "read"]
    }

    path   "*" {
      capabilities = ["list"]
    }
  }
}

This is counter to the way we normally expect policies to be additive.

[tgross]

@angrycub @mikenomitch this issue description makes me realize we probably need to come up with some standardized and documented name for the difference between:

• The implicit policy that gives a Workload Identity claim to secure variables that match it.
• The automatically-associated policy that doesn't exist until a user creates one with a matching name.

[mikenomitch]

The implicit policy that gives a Workload Identity claim to secure variables that match it - I think maybe this concept needs a name, but the actual "policy" itself feels like a code-level detail. So it could maybe use a variable name, but am I right to think that it won't be user facing?

The automatically-associated policy that doesn't exist until a user creates one with a matching name - Maybe just "the (namespace's|job's|group's|task's) Implicit Policy"?

[tgross]

I think maybe this concept needs a name, but the actual "policy" itself feels like a code-level detail. So it could maybe use a variable name, but am I right to think that it won't be user facing?

Yeah, in retrospect I think we want a name for this mostly for our own internal discussions because it's easy to mix up the two.

[tgross]

I think I've got an approach in mind for this but want to land #14140 first. I'll fork from that branch with the fix.

[tgross]

After a bit more investigation I discovered this is an invalid bug. The problem in the original description is that I've got an invalid policy document of the same sort of user error that we'll catch now with #14123. I've added an extra test to #14140 that demonstrates this is actually working just fine. 🤦

[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.