What are ACL policies and how can they be created?

ACL policies are the mechanism that Rundeck uses to determine what any user sees or can do based on the groups that user belongs to.  ACL policies can be created and edited in two primary ways: 1) in text files stored on the file system of the Rundeck server or 2) stored in the Rundeck database and created/edited through the Rundeck user interface.  Option 1 is available to all users (Community and Enterprise) but option 2 is available only to Enterprise customers.  In both options you can view and edit the policies as a properly formatted yaml file.  In option 2, Enterprise admin users can compose policies using an ACL “wizard” that lets them create a policy one rule at a time.

ACL policies are composed of one or more ACL rules.  All rules must have a “context” which is either specific to one or more projects or in the “system” or rundeck “application’ context.  It is important to remember that providing access to a particular user or group is likely always going to require 1 or more rules in the system context as well as 1 or more rules in a project context.  System context provides the generic ability to access one or more projects.  Project context rules will delineate what can be done inside the project itself.

This discussion focuses on the ACL “wizard” interface available in Rundeck Enterprise.   That being said, the principles should also apply if you are creating your ACLs as policy text files.  At the end, we include an example of what one of those text files looks like.

How can ACL policies be created in the UI and why are there two points of entry?

ACL policies can be initiated in two places.  If someone has administrative permissions within a specific project, you can find access control under the project settings menu in the left-hand panel.  For someone who has administrative access at the system level (such as the “admin” account), you can also find access control under the the gear icon at the top right of the screen.

Project ACLs

ACL policies created using the Access Control option in the Project Settings menu are automatically given the project context.  Essentially, in this mode you can only apply rules that affect what happens inside that particular project.  This approach is intended to support someone who is administrator for the project but doesn’t have the ability to define ACLs at the system level or for other projects.  As shown below, a project-level ACL will show the specific project on its main ACL policy page.

System ACLs

ACL policies created using the Access Control option in the administrative gear icon can have multiple contexts as needed.  Often, a policy created here will include some rules that have the system context and some that have project contexts.  Because the project context here isn’t limited to 1 project, these policies can be much more flexible, including being applicable to multiple projects using regex.  As shown below, a system ACL policy will show the location where the policy is being saved (Storage indicates it is being saved in the DB).  You’ll also notice a column that delineates the context for each rule (System or a project).

Components of an ACL Policy Rule

Each rule has several elements:

A Description

This could be anything but it is helpful if the description actually describes what this rule does

A Context

Either “System” or the name of a Project

A By clause

Determines how this rule applies to, as defined by usernames or (more commonly) an LDAP group

A For clause

This is the most complex and usually longest element in the rule.  The “For” clause defines what resources are being controlled by this rule

Resources in the “For” clause are dependent on which context the rule is being written for (application/system or project)

Details of the resources and actions for the application scope are detailed here though they are described in a way that is focused on text file ACL policies. The following screenshot shows the list of resources in the system context:

• • 

Details of the resources and actions for the project scope are detailed here though they are described in a way that is focused on text file ACL policies. The following screenshot shows the list of resources in the project context:

• 

An Action Clause

This is really a subsection of the For clause, identifying what actions will be allowed or denied for the identified resource

• 
  

  The editor view

  After rules have been added in the UI, you can see the configuration file that has been created through the UI.  Clicking the “Editor” link will give you a text editor-like view of the config, showing the detailed rules that have been specified.  If someone has an ACL Policy file that has been previously created as a text file on the file system, the text could be pasted in this editor view and it should allow further editing in this mode (and saving of the ACL in the database, if that is how the system is configured.