Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

RunDeck / ACL / Custom / for non-admin group

Tags:

acl

rundeck

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

like image 674
Cokorda Raka Avatar asked Oct 29 '16 18:10

Cokorda Raka


1 Answers

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
like image 193
jonatan Avatar answered Nov 10 '22 21:11

jonatan