Explains how to use RUNDECK ACL to control access to Rundeck

1. RUNDECK PRO
ACL Policy Convention Example

2. Rundeck’s ACL benefits
● Rundeck is great for enabling self-service and improving
collaboration between teams BUT…
○ InfoSec (“lock it down!”)
○ Compliance (“separation of concerns!”)
● Rundeck’s ACL lets you define policy so that you can
determine who can do what, and where they can do it
○ Separates out key tasks like running jobs, viewing
events/history, and writing jobs
○ Everything is logged and auditable, making Compliance,
InfoSec, and Managers more comfortable

3. About Policies
Rundeck governs access using an ACL policy.
Rundeck models capabilities as resources.
Resources have actions like “read” and “run”
A policy is a set of rules permitting or denying actions on a
resource for a given user or group.
Users and groups are managed in your user directory (LDAP)

4. About Projects
A project is a place for work activity.
An application team might each have a project.
A project can span one or more environments.
A RUNDECK admin will create projects for their
users

5. Projects, Environments & Nodes
Project activity happens across environments
A node is a member of just one environment.
Declare a Node attribute: “environment”
DIT Development integration test
UAT User acceptance test
STAGE Final release and staging
PROD Production operation

6. Example Project Nodes Model
<?xml version="1.0" encoding="UTF-8"?>
<project>
<node name="web1.DIT" tags="" hostname="web1.dit.domain" osFamily="unix" username="rundeck" environment="DIT" />
<node name="app1.DIT" tags="" hostname="app1.dit.domain" osFamily="unix" username="rundeck" environment="DIT" />
<node name="web1.UAT" tags="" hostname="web1.uat.domain" osFamily="unix" username="rundeck" environment="UAT" />
<node name="app1.UAT" tags="" hostname="app1.uat.domain" osFamily="unix" username="rundeck" environment="UAT" />
<node name="web1.STAGE" tags="" hostname="web1.stage.domain" osFamily="unix" username="rundeck" environment="STAGE" />
<node name="app1.STAGE" tags="" hostname="app1.stage.domain" osFamily="unix" username="rundeck" environment="STAGE" />
<node name="web1.PROD" tags="" hostname="web1.prod.domain" osFamily="unix" username="rundeck" environment="PROD" />
<node name="app1.PROD" tags="" hostname="app1.prod.domain" osFamily="unix" username="rundeck" environment="PROD" />
</project>
A node in
“PROD”
environment

7. Roles used in this example
● {TEAM}: Gives a team access to a Project(s)
Then these Roles give permissions within the context of a
Project...
● AUDIT: Activities (read)
● WRITE: Job writer (read, create, update, delete)
● RUN_STAGE: Jobs run on nodes in environments except
PROD
● RUN_PROD: Jobs run on nodes in PROD
These are only examples. Customize any roles you want!

8. Matrix of roles & groups for a project
AUDIT
WRITE
RUN_NON_PROD
RUN_PROD
Project A Project B Project C
manager eng SRE

9. Project-A
Policy: Allow users in Team-C to access Project-C
Project-B Project-C
{TEAM} Grant access to a project
A Team-C user
> Note: “{TEAM}” is a placeholder for a real team name (eg, “Team-C”)
“manager”

10. {TEAM}.aclpolicy
description: Given a user in group "{TEAM}" and for project name, {TEAM}, then allow
action [read].'
context:
application: 'rundeck'
for:
project:
- match:
name: {TEAM}
allow: [read]
by:
group: {TEAM}
Grants the team access to
their project
> Note: “{TEAM}” is a placeholder for a real team name (eg, “Team-C”)

11. Policy: AUDIT Allows: Read Events
history history history
Project A Project B Project ...
AUDIT Read job execution history
{TEAM}
“manager”

12. AUDIT.aclpolicy
description: 'Users in "AUDIT" can [read] events and nodes.'
context:
project: '.*'
for:
resource:
- equals:
kind: event
- allow: [read]
node:
- allow: [read]
by:
group: AUDIT
Read any event
Read any node

13. Policy: WRITE Allows: create,read,update,delete
WRITE.aclpolicy
Jobs Jobs Jobs
Project A Project B Project ...
{TEAM}
“eng”

14. WRITE.aclpolicy
description: Users in “WRITE” can change job definitions'
context:
project: '.*'
for:
resource:
- equals:
kind: job
allow: [create,delete]
job:
- allow: [create,read,update,delete]
by:
group: WRITE
Allow actions to change
job definitions

15. {TEAM}
Policy: RUN_NON_PROD Allows: Read,Run,Kill for Jobs
Allows: Read,Run for Nodes
environment match: ’UAT|DIT|STAGE’
UAT DIT STAGE
PROD
RUN_NON_PROD.aclpolicy
“eng”

16. RUN_NON_PROD.aclpolicy
description: 'Given user in group "RUN_NON_PROD" for any job, then allow [read,run,kill].'
context:
project: '.*'
for:
job:
- allow: [read,run,kill]
resource:
- equals:
kind: node
allow: [read]
node:
- match:
environment: 'DIT|UAT|STAGE'
allow: [read,run]
by:
group: RUN_NON_PROD
Just the non-PROD nodes

17. {TEAM}
DIT UAT STAGE PROD
RUN_PROD.aclpolicy
“SRE”
Policy: RUN_PROD Allows: Read,Run,Kill for Jobs
Allows: Read,Run for Nodes
environment equals: ’PROD’

18. RUN_PROD.aclpolicy
description: 'Given user in group "RUN_PROD" and any job, then allow [read,run,kill].'
context:
project: '.*'
for:
job:
- allow: [read,run,kill]
resource:
- equals:
kind: node
allow: [read]
node:
- equals:
environment: 'PROD'
allow: [read,run]
by:
group: 'RUN_PROD’
Just the PROD nodes

19. Example tomcat-users.xml
<tomcat-users>
<role rolename="AUDIT" /><!-- sees history -->
<role rolename="WRITE" /><!-- defines jobs -->
<role rolename="RUN_STAGE"/><!-- runs jobs on non-PROD nodes -->
<role rolename="RUN_PROD" /><!-- runs jobs on nodes in PROD -->
<user username="manager" password="***" roles="AUDIT"/>
<user username="eng" password="***" roles="AUDIT,RUN_STAGE"/>
<user username="sre" password="***" roles="AUDIT,RUN_PROD"/>
</tomcat-users>