understanding ACL's

[Jim Richard]

in reading the docs I keep seeing a pattern in the examples that I can't quite get my head around.

The following is an example from the RD docs and my confusion is the following; let's just look at resource type "job" here.

Regarding "job" I read this, top to bottom, basically as:

First, for "all" or "any" job, any resource that is of type "job"... allow "all actions"
and that's because we're using the generic resource declaration.

okay great but then...

a few lines later, and this is where I get confused....

we call out a specific resource type "job" (but with no matching or anything so I guess it still means "all" jobs) and we list 4 specific allowed actions.

but didn't we already allow "all" actions on any jobs already?

description: Project-level ACL for a specific Group for: resource: - equals: kind: node allow: [read,refresh] # allow refresh node sources - equals: kind: event allow: [read,create] # allows access to execution history - equals: kind: job allow: '*' #Project-level Access to Create and Delete Jobs job: - allow: [read,run,kill,killAs] # allow read/run/run/kill of all jobs node: - allow: [read,run] # allow read/run for nodes by: group: 'grp-sandbox-exec'

[Jim Richard]

I may have answered my own question, just let me know if my answer is correct...

short answer, this:  https://docs.rundeck.com/docs/administration/security/authorization.html#application-scope-resources-and-actions

for anyone trying to write ACL's an understanding of these 4 charts is absolutely critical.

generic resource "job" as in resource: >> job 
versus just job: .... with or without a match...

those charts show you that the actions you can control are not the same in both cases.

the "generic" or "all resources of type job" specification only gives you control of a small set of actions

as opposed to the more specific "job" which has many more actions that can be controlled

and finally it's important to note "application" versus "project" context here ^^^

I do have one more doubt which of course I can experiment to see but I'll ask anyways.

job: - allow: [read,run,kill,killAs] # allow read/run/run/kill of all jobs

there's no "match" here so this means "all" jobs right?

another way to say, if there's no match specified, it's implied to mean "all" ??

thanks !