A Rundeck access control policy grants users and user groups certain privileges to perform actions against rundeck resources like projects, jobs, nodes, commands and API. Every action requested by a user is evaluated by the Rundeck authorization system and logged for reporting and auditing purposes.
Since Rundeck respects the policy definition, you can define role-based authorization to restrict users to only a subset of actions. This enables a self-service type interface, where some users have access to a limited set of executable actions.
Two dimensions of information dictate authorization inside Rundeck:
The remainder of this section will describe how to use the access control policy.
Note from the project team: The authorization layer is an early work in progress. Please share your ideas on the IRC or mailing list.
Access to running or modifying Jobs is managed in an access control policy defined using the aclpolicy YAML document. This file contains a number of policy elements that describe what user group is allowed to perform which actions.
Please read over this document for information on how to define it, and how to grant access for certain actions to certain resources:
Policies can be organized into more than one file to help organize access by group or pattern of use. The normal Rundeck install will have generated a policy for the "admin" group. Not all users will need to be given "admin" access level to control and modify all Jobs. More typically, a group of users will be given access to just a subset of Jobs.
File listing: admin.aclpolicy example
description: Admin project level access control. Applies to resources within a specific project. context: project: '.*' # all projects for: resource: - equals: kind: job allow: [create] # allow create jobs - equals: kind: node allow: [read,create,update,refresh] # allow refresh node sources - equals: kind: event allow: [read,create] # allow read/create events adhoc: - allow: [read,run,runAs,kill,killAs] # allow running/killing adhoc jobs job: - allow: [create,read,update,delete,run,runAs,kill,killAs] # allow create/read/write/delete/run/kill of all jobs node: - allow: [read,run] # allow read/run for nodes by: group: admin --- description: Admin Application level access control, applies to creating/deleting projects, admin of user profiles, viewing projects and reading system information. context: application: 'rundeck' for: resource: - equals: kind: project allow: [create] # allow create of projects - equals: kind: system allow: [read] # allow read of system info - equals: kind: user allow: [admin] # allow modify user profiles project: - match: name: '.*' allow: [read,import,export,configure,delete] # allow full access of all projects or use 'admin' storage: - allow: [read,create,update,delete] # allow access for /ssh-key/* storage content by: group: admin
The example policy document above demonstrates the access granted to the users in group "admin".
group can use regular expressions to match multiple users or groups.
Two separate policies define two levels of access control. The first is the "project" context, which allows access to actions on resources within a specific project. The second is the "application" level context, which allows access to things like creating projects, access to projects, managing users, and access to system information.
As described in the aclpolicy-v10(5) definition, access is granted or denied to specific "resources". Resources can take two forms:
For example, you might want to restrict access to a job or jobs within a certain group. This corresponds to specific "job" resources with a "group" property matching a certain pattern.
You might also want to restrict who can create new jobs. Since a new job does not exist yet, you cannot create a rule for this action to apply to an existing job. Which means this corresponds to a generic resource with a "kind" called "job".
After defining an aclpolicy file to grant access to a particular group of users, you may find them getting "unauthorized" messages or complaints that certain actions are not possible.
To diagnose this, begin by checking two bits:
rundeck.audit.loglog file. The authorization facility generates fairly low level messages describing how the policy is matched to the user context.
For each entry in the audit log, you'll see all decisions leading up to either a AUTHORIZED or a REJECTED message. It's not uncommon to see REJECTED messages followed by AUTHORIZED. The important thing is to look at the last decision made.