Instead of using a strict xml schema, a markup language is used so new tags can be introduced in subsequent releases while preserving backwards compatibility.
Another benefit is that multiple aclpolicy files can be stored in the same directory, helping the management of each set of rules. This reduces the complexity of each file. The default path is
Policy files are parsed using YAML and while the structure is ridgid, additional information can be added and safely ignored. So creating arbitrary elements for documentation or organizational purposes is gracefully parsed.
The resulting file must be a valid yaml file.
In addition, existing XML formats are still supported to provide a transition.
A warning is given only once for each file that is detected to be xml in the log file.
An example policy document.
description: Yaml Policy 1 rules: ^$: actions: 'foobar' /yml: actions: 'exact_match' /yml.*: actions: pattern_match /listAction/.*: actions: [action_list_1,action_list_2] by: username: 'yml_usr_1' group: 'yml_group_1'
An .aclpolicy supports multiple policy definitions in the form of YAML documents usign the
--- separator. There are three elements that make a policy definition:
It's recommended that this description be short and descriptive as it appears in the log output.
by can be any number of
group elements. A single match will result in further evaluation of the policy.
username elements are evaluated first as they are typically more restrictive.
group elements are evaluated second. Ordering is not important within this element.
rules element contains a map of resource paths to
actions. The key in each rule, for example:
/path: actions: 'an_action'
/path is evaluated against the resource being evaluated. See below for a complete list of paths that can have ACLs applied. The path is evaluated as a java regex expression. If a match is successful, then a final check against
actions element is performed.
The actions element can be either a single value, or a list of values. A single value takes the form:
And a list takes the form:
Note that the single tick marks are optional according to the yaml specification.
Known path/actions combinations are:
|adhoc||adhoc||workflow_read, workflow_kill, workflow_read|
|*||*||workflow_read, workflow_create, workflow_update, workflow_delete, workflow_kill, workflow_run, events_read, events_create, events_update, events_delete, resources_read, resources_create, resources_update, resources_delete|
Possible values are limitless so it requires an understanding of the job definition you're trying to run. The best way to understand what the actions are is to look at the rundeck-audit.log. This will show all the options as they're being evaluated.
The RunDeck source code and all documentation may be downloaded from