rundeck acl magic
96 views
Skip to first unread message
Nate Amsden
Oct 20, 2021, 10:13:37 PM10/20/21
to rundeck-discuss
Hello there
I have been using Rundeck for about 10 years now, currently running 3.3.11
on top of tomcat.
One area my org has always struggled with is getting the ACLs right. I mean
literally it can take me 2 hours to get the syntax right to open a job to a given
So this time around I got a request to get access to a job. I had heard of
the rd acl command which I had never used before and decided to use it, with
mixed results.
Job details:
Project: Production
Job Name: "Production / Sanitization / Create DB Sanitized data"
Job UUID: 3d8a4b84-83f6-416a-a70f-4793bc9032c5
My objective was to grant the users in the dev group access to this
job, there are many ACLs in place already for this group so I just
added a new one
Here is a sample snip from the file, including the immediate two
previous job that work fine(first one is in the same project
the second job is in another project):
----
- equals: # allow read/run/kill of Cache Flush in Production
group: 'PROD/Production/common'
name: 'release-app-nemus-comparison'
allow: [run,read,kill]
- equals: # allow read/run/kill of Cache Flush in Production
group: 'PROD/Production/common'
name: 'stage-nemus-app'
allow: [run,read,kill]
- equals: # allow read/run/kill of this job
group: 'Production/Sanitize'
name: 'Create DB Sanitized data'
allow: [run,read,kill,view,view_history]
-----
(I don't need view,view_history just added those to see what rd acl
would show me)
So when I go to test this with rd acl I ran:
/var/lib/rundeck-cli/rd-cli-tool-shadow-1.3.4/bin/rd acl list --file dev.aclpolicy \
-g dev -p Production -j "Production/Sanitize/Create DB Sanitized data"
and it spit back, among other things
-----------------
# # Project "Production" access for group [dev]
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
+ read: Adhoc executions
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- delete: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ kill: Job "Production/Sanitize/Create DB Sanitized data"
- killAs: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ read: Job "Production/Sanitize/Create DB Sanitized data"
+ run: Job "Production/Sanitize/Create DB Sanitized data"
- runAs: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_create: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_delete: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_update: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- toggle_execution: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- toggle_schedule: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- update: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ view: Job "Production/Sanitize/Create DB Sanitized data"
+ view_history: Job "Production/Sanitize/Create DB Sanitized data"
-----------------
So that makes me think it should work, the things I granted are not REJECTED..
So to test it more completely I removed myself from the rundeck admin group in
LDAP and added myself to the rundeck dev group. However I was unable to
access the job, or even see that the job existed. If I tried to access the
job url directly I got access denied.
I knew it wouldn't affect anything(never has before) but I was at a loss so I
restarted tomcat, and of course the behavior remained the same.
Trying the rd acl again this time with the UUID for the job produced different
results:
/var/lib/rundeck-cli/rd-cli-tool-shadow-1.3.4/bin/rd acl list --file dev.aclpolicy \
-g dev -p Production -i 3d8a4b84-83f6-416a-a70f-4793bc9032c5
---------------------
# # Project "Production" access for group [dev]
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
+ read: Adhoc executions
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- delete: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- kill: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- killAs: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- read: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- run: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- runAs: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_create: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_delete: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_update: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- toggle_execution: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- toggle_schedule: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- update: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- view: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- view_history: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
---------------------
(side note at least in this version of the rd command appears to be at least
a couple issues, one is the command output of list says to use -I to query
the UUID but -i is what is required. Also above the lack of a space between
UUID and the double quotes am not sure if that is just a cosmetic thing or
perhaps another symptom of the problem querying via UUID.)
It's the same job?? I am just so totally confused why it is not allowing access.
However when I ran the same rd acl against the "working" job it gave the same
results, if I query the job name it shows it's good, if I query the job UUID
it shows REJECTED. But the job works if I put myself only in the dev group
I can see it and run it fine.
This is not a new problem, I struggled with this on Rundeck v1, and Rundeck v2,
and now Rundeck v3. Though I think more issues started with the acl format
change in Rundeck 2, I get the impression that it even cares about the number
of blank spaces on each line but that could just be coincidence. Most of the
time I could get it working, but since this is the first time using the rd
acl I figured I would have better success at getting the syntax right, so
am confused why it is rejecting. Started using Rundeck v3 back in June of
this year(first time I installed it from scratch, previous Rundecks were
setup by another person at the company).
My normal way of testing is:
- update the acl
- put my account in only the group that I want to test
- login to rundeck, see if it works
- if not, logout, and tweak acl again, and repeat, sometimes 20+ attempts
I've been using linux extensively since 1996(so no lack of experience with
config files etc), playing with acls in rundeck always makes me feel super
stupid.. Also as mentioned before I have been working pretty closely with
Rundeck for almost 10 years now so I'm by no means a newbie.
I've had so many Jackie Chan head scratching moments over the years regarding
rundeck acls I decided to finally ask what am I doing wrong?
(at this point in time I no longer need to add access to this acl, but
still am curious for the future if I can shorten the amount of time I
need to take to adjust an acl that would be nice)
thanks
nate
I have been using Rundeck for about 10 years now, currently running 3.3.11
on top of tomcat.
One area my org has always struggled with is getting the ACLs right. I mean
literally it can take me 2 hours to get the syntax right to open a job to a given
group sometimes(others on my team had similar issues, currently I'm the only
one on my team now). Looking at our old configs I think the syntax for ACLs in
rundeck v1 was easier than v2+. Anyway..So this time around I got a request to get access to a job. I had heard of
the rd acl command which I had never used before and decided to use it, with
mixed results.
Job details:
Project: Production
Job Name: "Production / Sanitization / Create DB Sanitized data"
Job UUID: 3d8a4b84-83f6-416a-a70f-4793bc9032c5
My objective was to grant the users in the dev group access to this
job, there are many ACLs in place already for this group so I just
added a new one
Here is a sample snip from the file, including the immediate two
previous job that work fine(first one is in the same project
the second job is in another project):
----
- equals: # allow read/run/kill of Cache Flush in Production
group: 'PROD/Production/common'
name: 'release-app-nemus-comparison'
allow: [run,read,kill]
- equals: # allow read/run/kill of Cache Flush in Production
group: 'PROD/Production/common'
name: 'stage-nemus-app'
allow: [run,read,kill]
- equals: # allow read/run/kill of this job
group: 'Production/Sanitize'
name: 'Create DB Sanitized data'
allow: [run,read,kill,view,view_history]
-----
(I don't need view,view_history just added those to see what rd acl
would show me)
So when I go to test this with rd acl I ran:
/var/lib/rundeck-cli/rd-cli-tool-shadow-1.3.4/bin/rd acl list --file dev.aclpolicy \
-g dev -p Production -j "Production/Sanitize/Create DB Sanitized data"
and it spit back, among other things
-----------------
# # Project "Production" access for group [dev]
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
+ read: Adhoc executions
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- delete: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ kill: Job "Production/Sanitize/Create DB Sanitized data"
- killAs: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ read: Job "Production/Sanitize/Create DB Sanitized data"
+ run: Job "Production/Sanitize/Create DB Sanitized data"
- runAs: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_create: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_delete: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- scm_update: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- toggle_execution: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- toggle_schedule: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
- update: Job "Production/Sanitize/Create DB Sanitized data" [REJECTED]
+ view: Job "Production/Sanitize/Create DB Sanitized data"
+ view_history: Job "Production/Sanitize/Create DB Sanitized data"
-----------------
So that makes me think it should work, the things I granted are not REJECTED..
So to test it more completely I removed myself from the rundeck admin group in
LDAP and added myself to the rundeck dev group. However I was unable to
access the job, or even see that the job existed. If I tried to access the
job url directly I got access denied.
I knew it wouldn't affect anything(never has before) but I was at a loss so I
restarted tomcat, and of course the behavior remained the same.
Trying the rd acl again this time with the UUID for the job produced different
results:
/var/lib/rundeck-cli/rd-cli-tool-shadow-1.3.4/bin/rd acl list --file dev.aclpolicy \
-g dev -p Production -i 3d8a4b84-83f6-416a-a70f-4793bc9032c5
---------------------
# # Project "Production" access for group [dev]
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
+ read: Adhoc executions
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- delete: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- kill: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- killAs: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- read: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- run: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- runAs: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_create: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_delete: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- scm_update: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- toggle_execution: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- toggle_schedule: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- update: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- view: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
- view_history: Job UUID"3d8a4b84-83f6-416a-a70f-4793bc9032c5" [REJECTED]
---------------------
(side note at least in this version of the rd command appears to be at least
a couple issues, one is the command output of list says to use -I to query
the UUID but -i is what is required. Also above the lack of a space between
UUID and the double quotes am not sure if that is just a cosmetic thing or
perhaps another symptom of the problem querying via UUID.)
It's the same job?? I am just so totally confused why it is not allowing access.
However when I ran the same rd acl against the "working" job it gave the same
results, if I query the job name it shows it's good, if I query the job UUID
it shows REJECTED. But the job works if I put myself only in the dev group
I can see it and run it fine.
This is not a new problem, I struggled with this on Rundeck v1, and Rundeck v2,
and now Rundeck v3. Though I think more issues started with the acl format
change in Rundeck 2, I get the impression that it even cares about the number
of blank spaces on each line but that could just be coincidence. Most of the
time I could get it working, but since this is the first time using the rd
acl I figured I would have better success at getting the syntax right, so
am confused why it is rejecting. Started using Rundeck v3 back in June of
this year(first time I installed it from scratch, previous Rundecks were
setup by another person at the company).
My normal way of testing is:
- update the acl
- put my account in only the group that I want to test
- login to rundeck, see if it works
- if not, logout, and tweak acl again, and repeat, sometimes 20+ attempts
I've been using linux extensively since 1996(so no lack of experience with
config files etc), playing with acls in rundeck always makes me feel super
stupid.. Also as mentioned before I have been working pretty closely with
Rundeck for almost 10 years now so I'm by no means a newbie.
I've had so many Jackie Chan head scratching moments over the years regarding
rundeck acls I decided to finally ask what am I doing wrong?
(at this point in time I no longer need to add access to this acl, but
still am curious for the future if I can shorten the amount of time I
need to take to adjust an acl that would be nice)
thanks
nate
rac...@rundeck.com
Oct 21, 2021, 3:25:02 PM10/21/21
to rundeck-discuss
Hi Nate,
I tested with the following ACL for the user “user”:
description: project context.
context:
project: ProjectEXAMPLE
for:
resource:
- allow: [run,read]
job:
- equals:
name: Job2
allow: [run,read]
node:
- allow: [read,run]
by:
username: user
---
description: app context.
context:
application: 'rundeck'
for:
project:
- match:
name: ProjectEXAMPLE
allow: [read]
storage:
- allow: [read]
by:
username: user
And evaluating with the following command: ./rd acl list --file user.aclpolicy -u user -p ProjectEXAMPLE -j Job2
I get the right permissions:
# # Project "ProjectEXAMPLE" access for username user
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
- read: Adhoc executions [REJECTED]
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job "Job2" [REJECTED]
- delete: Job "Job2" [REJECTED]
- kill: Job "Job2" [REJECTED]
- killAs: Job "Job2" [REJECTED]
+ read: Job "Job2"
+ run: Job "Job2"
- runAs: Job "Job2" [REJECTED]
- scm_create: Job "Job2" [REJECTED]
- scm_delete: Job "Job2" [REJECTED]
- scm_update: Job "Job2" [REJECTED]
- toggle_execution: Job "Job2" [REJECTED]
- toggle_schedule: Job "Job2" [REJECTED]
- update: Job "Job2" [REJECTED]
- view: Job "Job2" [REJECTED]
- view_history: Job "Job2" [REJECTED]
So, trying by uuid: rd acl list --file user.aclpolicy -u user -p ProjectEXAMPLE -i 1437576d-bf3e-4235-8bf5-2ac622ea8659
I obtain the bad result:
# # Project "ProjectEXAMPLE" access for username user
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
- read: Adhoc executions [REJECTED]
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- delete: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- kill: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- killAs: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- read: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- run: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- runAs: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_create: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_delete: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_update: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- toggle_execution: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- toggle_schedule: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- update: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- view: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- view_history: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
Drilling down the issue, it’s about how rd acl evaluates the ACL, if you define your ACL using the job name and evaluate by UUID then fails.
So, changing the ACL to indicate the job by UUID:
description: project context.
context:
project: ProjectEXAMPLE
for:
resource:
- allow: [run,read]
job:
- equals:
uuid: 1437576d-bf3e-4235-8bf5-2ac622ea8659
allow: [run,read]
node:
- allow: [read,run]
by:
username: user
---
description: app context.
context:
application: 'rundeck'
for:
project:
- match:
name: ProjectEXAMPLE
allow: [read]
storage:
- allow: [read]
by:
username: user
Then the evaluation by UUID looks ok:
# # Project "ProjectEXAMPLE" access for username user
- kill: Adhoc executions [REJECTED]
- killAs: Adhoc executions [REJECTED]
- read: Adhoc executions [REJECTED]
- run: Adhoc executions [REJECTED]
- runAs: Adhoc executions [REJECTED]
- view: Adhoc executions [REJECTED]
- create: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- delete: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- kill: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- killAs: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
+ read: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659"
+ run: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659"
- runAs: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_create: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_delete: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- scm_update: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- toggle_execution: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- toggle_schedule: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- update: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- view: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
- view_history: Job UUID"1437576d-bf3e-4235-8bf5-2ac622ea8659" [REJECTED]
(and fails if you evaluate by name).
Basically, if you define your jobs by name, use the -j parameter, if you define it using UUID, use the -i parameter.
Greetings.
Nate Amsden
Oct 21, 2021, 4:06:47 PM10/21/21
to rundeck-discuss
Ok thanks for confirming that behavior! Still stumped why the UI is not allowing access to the job when the rd acl says it is fine(when referencing the job by name)..... I will try messing with it more next week just to try to understand..
nate
Reply all
Reply to author
Forward
0 new messages