In Rundeck 1.4.0.x, the new ACL Policy format used an incorrect property key ("job") to check Job Authorizations by name. The correct key was used in all documentation, but not in the underlying code. The correct key is "name".
This issue has been fixed in Rundeck 1.4.1, however if you were using the incorrect key previously, you will have to change your aclpolicy files to the correct key.
The Project Scope Resources and Actions section shows the correct way to authorize Job resources by name:
for: job: - equals: name: bob allow: [run]
These changes in version 1.4 are important to note if you are upgrading an existing Rundeck installation.
Note: before upgrading, it is a good idea to back up your Rundeck installation using the instructions here: Backup and Recovery.
If you are using RPM or Debian packaging, refer to the basic Install Instructions, and simply upgrade the package.
For the Rundeck Launcher jar, you can follow this basic procedure:
rundeck-launcher-1.4x.jarfile either to your
$RDECK_BASEdirectory, or wherever you had your previous jar
-b basediroption, or leaving it off to use the directory the launcher jar is in.
Unfortunately, Rundeck 1.3 and earlier used domain class names that conflicted with some reserved words in Mysql and Oracle, specifically "user" and "option".
To fix this, we have changed the table/field mappings to "rduser" and "rdoption" for the domain classes that used these names.
The new table/field names are only used if a new config value is set to
true in the rundeck-config.properties file:
This value is set to
false by default on new installations, so if you have a previous 1.3 installation using the file-based datasource, upgrading to 1.4 should not cause any issues.
To configure a relational database backend, you must set this to "true". See the section in the Rundeck Guide Administration chapter: Enable rdbsupport.
NOTE: If you are installing Rundeck 1.4 from scratch, your installation will come with default aclpolicy files will get you up and running, this document is merely a guide for people upgrading from Rundeck 1.3 or earlier who have customized their aclpolicy files.
The simplest way to upgrade is to add or replace the "admin.aclpolicy" file with the Example admin.aclpolicy at the end of this document.
This will give full authorization to 'admin' role users.
*.aclpolicy files live in the Rundeck
Each file can contain multiple policy definitions, and there can be multiple files in the directory.
So when upgrading you have a few options for how to manage the transition from old to new file formats:
Leaving your old aclpolicy files in place will not cause any problems, because even though they are read by the authorization code they will simply not grant the necessary authorizations until converted to the new format.
Note: to add multiple policy definitions to a single file, use the YAML document separator "---" on a line by itself between the definitions.
The updated ACL Policy file format lets you allow and deny actions on particular resources for certain users and in certain contexts.
It is a more expressive language than the previous formats, although this adds some complexity.
The important new features are:
You now declare access control within a particular project or at the Application level. You specify this in the
Actions are allowed or denied for a particular Resource. If an action is to be restricted on all resources of a certain type, or for example on creating any resource of a certain type, then we use a Generic Resource Type as the Resource.
An example of this is: allow "run" action on a particular Job
[type: job, name: "Test Job", group: "my/group/path"]. All Resources have a particular "type" and some associated identifying properties.
Generic Resource Type
An example of this is: allow "create" action for jobs in general. The resource that would be tested is:
[type: resource, kind: job]. In this example, the type is genericized as "resource", and the identifying property is the "kind" which is "job".
The Resource for the authorization request is matched against the Resource Patterns defined in the ACL Policy to find Rules defined for it. Each Resource Pattern is specified first by the value of the "type" of the resource, and subsequently by different matching patterns on the properties of the resource. All matching Resource Patterns are applied to the request, and depending on the rules, the specific action is allowed, denied or rejected.
Each Resource Pattern can declare the set of Actions that it allows and/or denies. If a matching resource pattern rule allows an action, the action is marked temporarily as "allowed", but subsequent matching Resource Patterns and rules are still applied. If any matching rule Denies an action, the action is immediately denied. If no Resource Patterns match a resource, or no matching Patterns have a rule that allows the action, then the action is also denied.
The subject is the user or account to authorize the action for. They can be identified by name, or by group (role) membership in the
Action names have changed from the previous formats.
event_Y type action names, the actions have been simplified to this set, although not all actions are used by every kind of resource:
The actions are now specified directly on a resource or type in the aclpolicy definition.
You may have the old XML format in your current installation.
You can convert the XML to yaml:
<policies> <policy description="Administrative group that has access to execute all actions."> <context project="*"> <command group="*" job="*" actions="*"/> </context> <by> <group name="admin"/> </by> </policy> </policies>
This would convert to:
description: Administrative group that has access to execute all actions. context: project: '.*' for: job: - equals: group: '.*' name: '.*' allow: '*' by: group: admin
However, this YAML document merely allows access to certain Jobs, and it doesn't allow any access to application level resources, or other project level resources besides jobs. You must add that access as you see fit.
Here is a XMLStarlet command to convert your xml to the supported yaml format:
FILE=$RDECK_BASE/etc/role.aclpolicy NEWFILE=$RDECK_BASE/etc/role-new.aclpolicy xmlstarlet sel -t --match '//policy' -o '---' -n -o 'description: ' -v '@description' -n \ -o 'context: ' -n -o ' project: "' -v 'context/@project' -o '"' -n \ -o 'for:' -n \ -o ' job:' -n \ --match 'context/command' \ -o ' - equals: ' -n \ -o ' group: "' -v '@group' -o '"' -n \ -o ' name: "' -v '@job' -o '"' -n \ -o ' allow: "' -v '@actions' -o '"' -n \ -b \ -m 'by/group' \ -o 'by:' -n \ -o ' group: "' -v '@name' -o '"' -n $FILE > $NEWFILE
Your yaml aclpolicy file may be out of date, and look like this:
description: Yaml Policy 1 rules: ^$: actions: 'foobar' /groupa/.*: actions: 'exact_match' .*/job1: actions: pattern_match /listAction/.*: actions: [action_list_1,action_list_2] by: username: 'yml_usr_1' group: 'yml_group_1'
You can convert each "rules:" entry to a job resource pattern. For example the rule value ".*/job1" matches only jobs named "job1":
for: job: - equals: #use "equals" to match exactly name: 'job1' # compare name property only, ignore group allow: [read]
And a rule value of "/groupa/.*" matches any jobs in group "matcha" or a subgroup. The equivalent is:
for: job: - match: # use "match" to match via regular expression group: '^groupa/.*$' # compare group property, ignore name allow: [read,run] deny: [delete,update,kill]
Note, if you need to authorize actions on adhoc executions, use the 'adhoc' resource type and allow/deny the "run" and "kill" actions:
for: adhoc: - allow: [run,kill]
Mapped roles defined in
rundeck-config.properties were used to authorize actions in the Rundeck GUI in Rundeck 1.3 and earlier.
Here is the list of old "application roles", and how to translate them into the new aclpolicy format:
"Admin" is no longer a special role given any special access other than the access granted to it in aclpolicy.
The "admin" action can be granted on generic resources of kind "user" at the application context level.
The "create" action can be granted on generic resources of kind "job" at the project level.
For actions other than "create", ("read", "update", "delete", "run", "kill"), you can grant them to specific "job" resources within a project context.
: You can grant "read" and "create" to generic resources of kind "event" at the project level.
: You can grant ("read", "create", "update") to generic resources of kind "node" at the project level. You can also grant "refresh", which allows refreshing the Node resources from a predefined URL.
This file grants all authorizations to 'admin' role, and explicitly enumerates the actions granted for each resource. It could be simplified into a much shorter file by allowing '*' and not explicitly matching the resources.
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: [run,kill] # allow running/killing adhoc jobs job: - allow: [create,read,update,delete,run,kill] # 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,admin] # allow view/admin of all projects by: group: admin