Having trouble to get user that belongs to group "user" having access (at least read) to projects. I've read and tried several examples I found on the internet, none seems to work.
What I need for now is: allow any users who belong to group "user" to read project named MYPROJECT. I have this, saved in a file named user.aclpolicy under /etc/rundeck. I have waited for 60+ seconds. I've also tried restarting RunDeck. No luck.
I keep getting:
You have no authorized access to projects. Contact your administrator. (User roles: raka, user)
description: application access to a project
application: 'rundeck'
for:
resource:
- equals:
kind: project
deny: [create] # deny create of projects
- equals:
kind: system
allow: [read] # allow read of system info
- equals:
kind: user
deny: [admin] # allow modify user profiles
project:
- equals:
name: 'MYPROJECT'
allow: [read] # allow access
deny: [import,export,configure,delete] # deny admin actions
storage:
- deny: [read,create,update,delete] # allow access for /keys/* storage content
by:
group: user
What's wrong with YAML above? I've also checked the web.xml under /var/lib/rundeck/exp/webapp/WEB-INF to make sure role-name "user" is registered there.
My realm.properties contains this line:
raka:greentooth60,user
I've also tried this. Basically copying whatever was there for the "admin" group. And for that I also tried it putting it direcly in the admin.aclpolicy instead of separate file. Still no luck.
description: User, all access.
context:
project: '.*' # all projects
for:
resource:
- allow: '*' # allow read/create all kinds
adhoc:
- allow: '*' # allow read/running/killing adhoc jobs
job:
- allow: '*' # allow read/write/delete/run/kill of all jobs
node:
- allow: '*' # allow read/run for all nodes
by:
group: user
RunDeck version: Rundeck 2.6.9-1 cafe bonbon indigo tower 2016-08-03
This is a debian installation of RunDeck (.deb). Which log file(s) can I look at to analyze situations like this?
Thanks, Raka
RunDeck ACLs can be counter-intuitive and take some time to get used to. For visibility, especially when you are starting out writing RunDeck ACL policies, it is better to only set what users are allowed to do, instead of denying access. By default, nothing is allowed, so you only really need to add allow
statements to give users access to resources.
RunDeck needs ACL policies for both the "application" context, and the "project" context. You are specifying read
access to the project in the application context, and access to all jobs by name (in your case .*
) in the project context, but there you also need to give access to read
the resource type job
in order for jobs to be visible. See the example below.
For troubleshooting RunDeck I have found the following logs useful:
tail -f /var/log/rundeck/{rundeck.log,service.log}
If you want to test specific user actions against your ACL files, you can use the tool rd-acl
which is installed together with RunDeck. For example, to test that a member of group user
can read the job restart some server
in the project MYPROJECT
, you can do:
rd-acl test -p 'MYPROJECT' -g user -c project -j 'restart some server' -a read
For more details, see the rd-acl manual.
Here is an example (tested on Rundeck 2.6.9-1
) that should give anyone in the group "user" access to read everything on your RunDeck server:
context:
application: rundeck
description: "normal users will only have read permissions"
for:
project:
- match:
name: '.*'
allow: [read]
system:
- match:
name: '.*'
allow: [read]
by:
group: user
---
context:
project: '.*'
description: "normal users will only have read permissions"
for:
resource:
- equals:
kind: 'node'
allow: [read,refresh]
- equals:
kind: 'job'
allow: [read]
- equals:
kind: 'event'
allow: [read]
job:
- match:
name: '.*'
allow: [read]
node:
- match:
nodename: '.*'
allow: [read,refresh]
by:
group: user
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With