Restricted Operations Using Rundeck

As part of our migration to using Ansible for configuration management within the hosting team, we have begun to introduce Rundeck as a means of allowing users without direct shell access to servers the means to execute drush commands.

Rundeck is an Open Source job runner, providing a web-based interface to enable users to dispatch commands to remote nodes without the need to access them directly.  Rundeck offers many features including the ability to execute jobs (a collection of commands to be dispatched to a node), ad-hoc commands and scheduling.

In our case we wanted to make use of the ‘jobs’ feature to provide a pre-defined list of options a user could select from.  In some cases it was desirable for the user to be able to specify parameters such as start and end dates, for this Rundeck provides the ability to request input from the user prior to execution.

When selecting a job for execution, Rundeck connects to the target nodes as the user ‘rundeck’ and executes the commands dispatched as part of the job.  In our case this presented permission issues as some of the drush commands to be executed required write access to directories owned by the user www-data (Nginx/PHP user).  To overcome this the rundeck user on the remote nodes was granted sudo access.  With sudo privileges it was now possible for Rundeck to connect as the user ‘rundeck’  and switch to the www-data user to execute the drush commands.

When executing ‘jobs’, Rundeck logs all activity for review and to report the status of an execution.  This feature proved especially useful allowing for easier diagnosis of drush execution errors.  When a user reported issues with the execution of a drush command, the output was available for review within Rundeck.

Similarly the logging of job executions allows users to review the progress of a job.  This is especially useful for situation where a job may run for several hours such as refreshing search caches.  Users are able to return to Rundeck at a later date to review the execution of the job.

A crucial feature of Rundeck essential for our implementation is the ability to restrict the functionality of a user.  Rundeck implements ACL policies to allow fine grained control over a users abilities within Rundeck.  In our case we needed to restrict a user to having the ability to execute pre-defined jobs and view their execution status and output.  All other functionality within Rundeck was denied to the user such as the ability add and edit jobs.

description: Developer Project Policy
context:
project: 'example-project'
for:
resource:
- equals:
kind: job
allow: [read,run] # allow read run jobs
- equals:
kind: node
allow: [read,refresh] # allow read and refresh nodes
- equals:
kind: event
allow: [read] # allow read events
adhoc:
- deny: '*' # deny running/killing adhoc jobs
job:
- match:
group: '.*'
allow: [read,run,kill] # allow reading, running, killing all jobs
node:
- allow: '*' # allow read/run for all nodes
by:
group: [example]

---

description: Developer Application Policy
context:
application: 'rundeck'
for:
resource:
- equals:
kind: project
deny: [create] # prevent creation of projects
- equals:
kind: system
deny: [read]
- equals:
kind: user
deny: [admin]
project:
- match:
name: 'example'
allow: 'read' # restrict access to care quality commision project only
by:
group: [example]

The above is an example of how we implement ACL policies for users to a given project.  In this case the rules are applicable to the example project and users within the example group.

ACL policies within Rundeck also provide the ability to restrict the projects defined in Rundeck a user has access to.  With this it is possible to limit users to a given project and to specific functionality within the project.  As a result it is possible to have a single installation of Rundeck used by several users across several projects.