ACL questions

[James Edwards]

Hi all,

I have two AD groups setup - USER and DEV - and I'm trying to limit what each group can do.  If I have an AD user who is only part of USER, or only part of DEV, permissions work as expected.  If I have a user who has both USER and DEV group membership, permissions fail to work properly. 

When a user is a member of both USER and DEV, it appears that both policies get partially applied.  What I am seeing is the 'Configure Project' button available (when it is not present for a user that is only in USER), and the inability to run ad-hoc jobs (which is present for DEV). 

I have the following acl policies setup in /etc/rundeck/adgroup.aclpolicy:

description: Developer Access
context:
  project: '.*' # all projects
for:
  resource:
    - allow: '*' # allow read/create all kinds
  adhoc:
    - allow: '*' # deny read/running/killing adhoc jobs
  job:
    - allow: '*'
  node:
    - allow: '*' # allow read/run for all nodes
by:
  group: [DEV]

---

description: Developer Access
context:
  application: 'rundeck'
for:
  resource:
    - deny: '*' # deny creation of projects
  project:
    - allow: [read,configure,import,export] # allow view/admin of all projects
  storage:
    - deny: '*' # deny read/create/update/delete for all /keys/* storage content
by:
  group: [DEV]

---

description: Limited User Access
context:
  project: '.*' # all projects
for:
  resource:
    - allow: '*' # allow read/create all kinds
  adhoc:
    - deny: '*' # deny read/running/killing adhoc jobs
  job:
    - allow: '*'
  node:
    - allow: '*' # allow read/run for all nodes
by:
  group: [USER]

---

description: Limited User Access
context:
  application: 'rundeck'
for:
  resource:
    - deny: '*' # deny creation of projects
  project:
    - allow: [read] # allow view/admin of all projects
  storage:
    - deny: '*' # deny read/create/update/delete for all /keys/* storage content
by:
  group: [USER]

Also, in what order are ACLs applied, or does order matter?

Any suggestions?  Thanks in advance!
James

[Greg Schueler]

Hi James,

A few things to keep in mind about the ACL policies:

* order doesn't matter: all matching rules apply to the subject (user or group), resource and action which is being evaluated

* no actions are allowed by default, so if there is no *allow* for an action, it will be rejected

* *deny* rules take precedence over *allow* rules, so any *deny* rule will cause the action to be rejected, even if there are any matching *allow* rules

It may make more sense to just be explicit about what is allowed for each group (DEV and USER), and leave out anything you don't want to allow, rather than using *deny* in this case. 

--
You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Edwards]

Greg,

Thank you for your explanation, I used [read] instead of deny, which now has the desired results.  For example, a user in the DEV and USER group can now run ad-hoc commands, and now solves the issue of people in the USER group being able to edit jobs.

Thanks,
James

[James Edwards]

Just to follow up on this, my issue appeared to be a lowest match wins, however, ultimately my acl policies were not being applied.  I discovered that some of the acl policies were owned by root and rundeck did not have read access to read the file, but the acl policy shows to be in use under the 'Security' tab (to recreate this, as root, 'touch /etc/rundeck/TEST.aclpolicy', chmod it to 600, and then check Security).

All is resolved now.

Thanks,
James

[John Matheson]

This is great information guys. Can I ask one question, further to this post? 
As you were using two AD groups (which I wish to also do), how did you configure the security-role in web.xml to allow this to take place?

 

Thanks,

John

[James Edwards]

Hi John,

I'm using 'user' in the web.xml file, but I am also using 'supplementalRoles="user"' in my login configuration, so all users will be given 'user'.

web.xml:

        <security-role>
                <role-name>user</role-name>
        </security-role>

root@uniquehostname:/etc/rundeck# cat jaas-multiauth.conf
multiauth {

  com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule sufficient
    debug="true"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    providerUrl="ldap://ldap.example.com:3268"
    bindDn="CN=Rundeck Auth,OU=Users,DC=example,DC=com"
    bindPassword="PASSWORD"
    authenticationMethod="simple"
    forceBindingLogin="true"
    userBaseDn="DC=example,DC=com"
    userRdnAttribute="sAMAccountName"
    userIdAttribute="sAMAccountName"
    userPasswordAttribute="userPassword"
    userObjectClass="user"
    roleBaseDn="OU=Groups,DC=example,DC=com"
    roleNameAttribute="sAMAccountName"
    roleMemberAttribute="member"
    roleObjectClass="group"
    cacheDurationMillis="3000"
    supplementalRoles="user"
    reportStatistics="true"
    nestedGroups="true";

  org.eclipse.jetty.plus.jaas.spi.PropertyFileLoginModule required
    debug="true"
    file="/etc/rundeck/realm.properties";
};

realm.properties:
  admin:XXXXXX,user,admin,architect,deploy,build

I've got three different groups that will be logging in - Admins, Developers, and Users, which permissions will be handled via ACLs, so I have an admin.aclpolicy, dev.aclpolicy, and user.aclpolicy that handle permissions.  Adding additional groups will be as simple as creating a new policy and granting the AD groups permissions.

James

[John Matheson]

Excellent,  That works a treat.

Thank you James!