RunDeck / ACL / Custom / for non-admin group
Asked Answered
R

2

6

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

Repent answered 29/10, 2016 at 18:37 Comment(0)
P
10

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
Prioress answered 8/11, 2016 at 13:33 Comment(0)
G
5

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.

Geronto answered 10/8, 2018 at 16:58 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.