RunDeck / ACL / Custom / for a group without an administrator

Question

There were problems getting a user belonging to the user group that has access (at least read) to the projects. I read and tried several examples that I found on the Internet, but no one works.

Now I need to: allow all users belonging to the user group to read the project named MYPROJECT. I have this saved in a file called user.aclpolicy in / etc / rundeck. I waited another 60 seconds. I also tried restarting RunDeck. Bad luck.

I keep getting:

You do not have 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 happened to yaml above? I also checked web.xml under / var / lib / rundeck / exp / webapp / WEB -INF to make sure the username is registered there.

My realm.properties contains this line:

 raka:greentooth60,user 

I also tried this. Mostly copying was for the "admin" group. And for this I also tried to install it directly in admin.aclpolicy instead of a separate file. Not lucky yet.

 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 the Debian RunDeck installation (.deb). What log files can be viewed to analyze such situations?

Thanks, Raka

Answer 1

ACL RunDeck can be intuitive and take some time to get used to. For the sake of visibility, especially when you start writing ACL RunDeck policies, it is better to install only what is allowed to users, instead of denied access. Nothing is allowed by default, so you really need to add allow statements to give users access to resources.

RunDeck requires an ACL policy for both the application context and the "project" context. You specify read access to the project in the context of the application and get access to all tasks by name (in your case .* ) In the context of the project, but you also need to provide access to the read type of the job resource so that the tasks are visible. See the example below.

Useful Magazines

For troubleshooting RunDeck, I found the following useful logs:

 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 rd-acl tool that is installed with RunDeck. For example, to verify that a member of the user group can read the restart some server task in the MYPROJECT project, you can do:

 rd-acl test -p 'MYPROJECT' -g user -c project -j 'restart some server' -a read 

See the rd-acl manual for details.

Read-Only ACL Example

Here is an example (tested on Rundeck 2.6.9-1 ) that should let someone in the user group access 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