RunDeck / ACL / Custom / for non-admin group - acl

Question

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

Answer 1

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.
Useful logs
For troubleshooting RunDeck I have found the following logs useful:
tail -f /var/log/rundeck/{rundeck.log,service.log}
Testing ACL policies
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.
Read-only ACL example
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

Answer 2

Another thing you can stumble upon when dealing with the "You have no authorized access to projects" are the permissions.
If for whatever reason you have created the aclpolicy file with a simple copy using the root user, you will need to change the owner and group to 'rundeck' (unless you changed the user rundeck runs under, of course).
That made me loose 30 minutes today, hope this helps someone.