Role-based access control enhancements in Red Hat Ansible Automation Platform 2.5

Now that Red Hat Ansible Automation Platform 2.5 is out the door with a slew of great new features, let's take a closer look at the enhancements in the role based access control (RBAC) system. It can be tricky to align the default model with differing organizational structures, so our latest improvements are designed to make this integration smoother and more intuitive.

Try Ansible Automation Platform

Users often want some variation of, “As a user of the platform I want to create objects for myself or my team in an organization I am a member of,” and this was indeed not possible for objects like projects, inventories and credentials, all required objects needed to create job templates. You could only create your own job templates using existing projects, inventories and credentials if someone with the right admin roles granted you the correct access to them.

In Ansible Automation Platform 2.5, the RBAC system has been enhanced to give users a more intuitive way of setting up the RBAC model, and includes:

• The ability to create custom roles
• The ability to have “add” permissions on content types
• The introduction of team administrators

Let’s look at each of these new features in turn.

Custom roles

First is the ability to create custom roles. Here is a screenshot of the new UI for roles within the Access Management section:

As you can see, we now have a central place for managing access, which is one of the main enhancements in Ansible Automation Platform 2.5. This includes tabs for Automation Execution, Automation Decisions and Automation Content, the three main components within the platform. In the above example, you see the tab for Automation Execution where you can now create roles. In the list, you see which roles are built-in and which are not.

Let’s see what is needed to create a new custom role:

First you need to give the custom role a name and an optional description. Then you choose a single content type for the custom role, for example: Inventory.

After choosing the content type, you can choose multiple permissions from this content type for this custom role.

When you create the custom role, you can distinguish them from built-in roles in the list as being marked as “editable”. You can then assign these roles to teams and users in the same way that you can assign built-in roles.

“Add” permissions

The second enhancement is the ability to add permissions at the organizational level. Have a look at how you can create a custom role that enables you to add permissions on projects, inventories, credentials and workflows (as an example):

Again, you can assign this custom role to any team or user in your organization. With these roles assigned, a user can now create projects, inventories, credentials and workflows in the organisation without the need to be an admin for those content types.

When the user creates these objects, the user will automatically become admin for them. Here is an example for a project created using this permission:

Nobody else has access to these new objects, but the user that created it can add users or teams to it.

Team administrator role

Finally, there is now the option to assign one or more users as team administrators. You can see this in the screen below:

Team administrators can be any users in the team’s organization. They do not have to be team members first. So what can a team administrator do that a team member cannot? Change anything related to the team, including memberships, administrators, details and roles.

The ability to create custom roles is not limited to the Automation Execution tab, but is also possible with the RBAC model for the Automation Decisions and Automation Content tabs, and the same is true for adding permissions.

Learn more about Ansible Automation Platform