Restricted Operations Using Rundeck

Post by Michael A Picture of Michael A
Reading time 3 mins clock

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
project: 'example-project'
- 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
- deny: '*' # deny running/killing adhoc jobs
- match:
group: '.*'
allow: [read,run,kill] # allow reading, running, killing all jobs
- allow: '*' # allow read/run for all nodes
group: [example]


description: Developer Application Policy
application: 'rundeck'
- equals:
kind: project
deny: [create] # prevent creation of projects
- equals:
kind: system
deny: [read]
- equals:
kind: user
deny: [admin]
- match:
name: 'example'
allow: 'read' # restrict access to care quality commision project only
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.


Michael A

Systems Engineer


I'm working with Drupal trying to set up continuous delivery etc using Ansible as well.

I've got Rundeck downloaded, but then I saw Ansible Tower, though I haven't had a chance as yet to really compare the two.

Did you look at Ansible Tower as well before choosing Rundeck?


Hello Drew,

We had investigated Ansible tower as part of our move to Ansible as a whole. However the pricing options at that time were too much to justify based on our needs and requirements.

In our use case Ansible Tower was unsuitable as it was cumbersome and required the user have a level of knowledge regarding the workings of Ansible. On the contrary we simply wanted to provide a method of allowing a user to execute a series of commands on a remote server and log the execution for debugging purposes in the event of errors. For this usage Rundeck was ideal as it provided the ability to define access restrictions and a simple interface and workflow for the user.



Michael A

In reply to by Drew

I've been thinking about implementing rundeck for a similar purpose and this article is quite helpful for my evaluation. How are you doing user provisioning? For example, if a new developer joins the team how do you associate them with one of the ACL policies?


Hello Matt,

We presently control the ACL policies using groups. When a user is created they are associated with a specific ACL group within the configuration file. That ACL group is then allocated to the specific ACL policy within the user.aclpolicy configuration file.

This is a very simplistic approach and something I will be looking to refactor within our setups. The Rundeck Github project has some good examples of configuring ACL policies in a module manner using groups.



Michael A

In reply to by Matt

the contrary we simply wanted to provide a method of allowing a user to execute a series of commands on a remote server and log the execution for debugging purposes in the event of errors.


Thanks, Michael. This ACL Policy is exactly the example I was looking for. 

Zack Betz

had a question to rundeck adhoc permissions:

Is it possible to deny command execution for localhost or specific node and allow for other nodes?


Hi Michael,

  I wanted to give project level access control. All users are part of admin group and they have access  to all project. I wanted to apply a policy where users can only edit ,modify ,delete  the project only they created for other projects they can execute ,read the project..



Add new comment

Share this article

Sign up to our newsletter!

Our thoughts

Let's work together

Get in touch and find out how we can empower your organisation.
Back to top