6

Configuring Role-Based Access Control

Role-Based Access Control (RBAC) permissions are used to delegate access in both the Automation controller and hub. By default, system administrators have access to create and edit everything; however, in most environments, access should be limited to the minimum permissions needed to run. To achieve this, there are a variety of roles designed to grant that permission.

This chapter is broken up into the following sections:

• Assigning RBAC to the Automation controller
• Assigning RBAC to the Automation hub

Each of these sections covers its respective service. In each section, the different roles that can be granted will be covered, along with how to grant those roles to users; finally, each section will go into brief detail about how to use the roles practically for each service.

Technical requirements

This chapter will go over the platform and methods used in this book. All code referenced in this chapter is available at https://github.com/PacktPublishing/Demystifying-the-Ansible-Automation-Platform/tree/main/ch06. It is assumed that you have Ansible installed in order to run the code provided.

In addition, it is assumed that both an Automation controller and hub have been installed. This chapter will also go into setting RBAC with the hub and controller.

Assigning RBAC to the Automation controller

During the previous chapters, organizations, teams, and users were created. However, unless the users are admins, they have limited access inside the Automation controller.

Roles in the Automation controller follow the basic rules of RBAC . This means that each role has a set of permissions for what it is allowed to do. These roles fall into categories of allowing objects to be viewed, edited, and executed with the controller. In addition, the roles themselves are attached to organizations, teams, and users. Teams and users are interchangeable; it’s just that teams are a collection of users.

In addition, there is a hierarchy of roles. The hierarchy of roles follows inheritance. Some roles inherit permissions from other roles. The way to think of this is that a read role can only read, a user role can read and use an object, and an admin role can edit, use, and read an object.

The roles available in the Automation controller and their corresponding module options are the following:

Figure 6.1 – Object roles

These roles can be applied to a user or team to grant authority for doing individual actions. An admin has all the privileges below it.

Job templates are made up of specific parts, a project that contains the playbook, the inventory to run on, and it may or may not have a credential. Even if a user is assigned admin privileges on a job template, they may not have access to the underlying project, inventory, or credential. In order to add one of these to a given job template in editing, they must have use privileges for the item to be added. To have full access to change everything, the user or team would need to have full admin access to the job template, project, inventory, and credential. The same pertains to projects that need credentials as well when editing them.

use, update, and execute, and adhoc are different, and fall under a usage category. The user does not need to have access to the underlying objects to have usage of them.

The auditor role is special, as it is an elevated read role, but it is specifically provided for denoting a user or team that would need full read access but not any other access. It also works well for a service account that is specifically for reading logs and other Tower information that should not have other access.

In addition to the previous roles, there are organizational admin roles:

Figure 6.2 – Admin roles

These roles give admin control over all objects of the given type for an organization. Just short of system administrators, it gives the user or team full access to all objects of that type in an organization.

Important Note

Systems roles such as auditor and administrator can only be applied to users using the user module and API endpoint, not with the role methods discussed in this section. Refer to Chapter 4, Configuring Settings and Authentication, on how to set those.

Applying these roles consists of three parts:

• Who is being given permission?
• To what object is the permission being granted?
• What role is being applied?

Navigate to the organization, team, or user in the GUI that you wish to edit access for.

Figure 6.3 – Adding access to an organization

For organizations, navigating to Organizations | organization name | Access will open an interactive tool to apply various roles to users and teams. The same can be done for users or teams by navigating to the corresponding user or team and selecting Roles | Add.

To give admin permission to an inventory for a user, using a module, the roles/set_role_using_module.yml playbook would be used. The following gives the user administrator rights over the given inventory:

    - name:  Set user to admin over inventor
      ansible.controller.role:
        user: joe123
        role: admin
        inventories:
          - Demo Inventory
…

Using the module can be especially useful for creating dynamic or new objects in the Automation controller and granting granular access to them immediately. However, using Configuration as Code (CaC) to maintain access control is the recommended method.

Finally, using the redhat_cop.controller_configuration roles that implement the module, it’s easier to loop over the module and define the definitions as code. The following two list items give the satlab team and the joe123 user admin permissions to a project and a job template respectively:

// roles/set_role_with_roles.yml
---
   controller_roles:
     - projects:
         - Demo Project
       job_templates:
         - Demo Job Template
       team: satlab
       role: admin
     - projects:
         - Demo Project
       job_templates:
         - Demo Job Template
       user: joe123
       role: admin

The roles role in the controller configuration applies the definitions from the preceding code to the Automation controller:

 roles:
   - redhat_cop.controller_configuration.roles
…

The role and module-based methods work well for maintaining the granular access for RBACs. One permission that is commonly overlooked is the approval permission for workflows.

Approval permissions for workflows

The details on approval nodes will be covered in the chapter about workflows; however, the approval role has its own place in RBAC. While those who can create and edit workflows have the right to create approval nodes and those with read access to workflows can see approvals, those with execute permissions on a workflow do not automatically have the ability to approve or deny approvals; that permission must be granted to the user or group. More details about workflow approvals can be found in Chapter 10, Creating Job Templates and Workflows, and here: https://docs.Ansible.com/Ansible-tower/latest/html/userguide/workflow_templates.html?#approval-nodes.

For those workflows where approvals are merely for a user to review before continuing, or where the approval is used to pause a workflow, workflow approval can be granted. In other case, the executing user may not be the one doing the approving but another team instead.

It is important to remember when using approval nodes that extra permissions must be granted to users to take advantage of them.

With the RBAC options covered, how can you practically set a system to govern access?

Practically using the RBACs

With the Automation controller, users fall into two camps – those who need to edit and those who need to run. If running CaC and being strict about it is the only way to change configuration, admin privileges can be locked to service accounts to make changes. For Enterprise users running jobs, the three things really needed to run are executing privilege on job templates that are not in workflow, workflows, and approval rights for the correct teams, and nothing more.

For developers doing testing and the tweaking of job templates and workflows, it is often easier to have them in separate organizations with admin control over everything, or even a fully separate development Automation controller instance that they have full systems admin access to.

In the end, the controls can be set up to be permissive or strict, whichever the administrators prefer.

Assigning RBAC to the Automation hub

Automation hub RBACs work much like the Automation controller. There are a few categories of roles, each granting access to a different aspect of the Automation hub. The categories are as follows:

• User management.
• Group management.
• Collection namespace: Collections are named with two parts, such as redhat_cop.ah_configuration. The first half before the dot is the namespace – in this case, redhat_cop.
• Collection management: Used to manage collections that are not part of remote collections.
• Remote collection management: Used to manage remote collections from either of the following:
  • Red Hat certified collections
  • Ansible Galaxy
  • Container registry management: Used to manage the container registry.
  • Task management.

Groups with these permissions can manage user configuration and access:

Figure 6.4 – User roles

Groups with these permissions can manage group configuration and access:

Figure 6.5 – Group roles

The following are the namespace permissions; groups with these permissions control collection namespaces:

Figure 6.6 – Namespace roles

Groups with the modify_ansible_repo_content permission can move content between repositories using the approval feature. They can certify or reject features to move content from the staging, which is where collections sit pending approval, to published or rejected repositories:

Figure 6.7 – Collection roles

Groups with these permissions can configure remote repository syncing from community or Red Hat certified sources under repository management:

Figure 6.8 – Remote collection roles

Groups with these permissions can manage the container registry:

Figure 6.9 – Container roles

Groups with these permissions can manage tasks:

Figure 6.10 – Task management roles

Important Note

The Super user permission can only be applied to users using the GUI, the user module, and API endpoint, not with the role methods discussed in this section. Refer to Chapter 4, Configuring Settings and Authentication for how to set that permission.

However, with the module and role, an additional permission exists of either ‘*’ or ‘all’ to assign all the preceding permissions to a user without granting them system administrator status.

Setting roles in the GUI

Roles in the GUI are done for each group on a single page. The process is relatively easy.

To set roles in the GUI, use the following steps:

1. Navigate to and click on User Access on the left-hand side, and then click on Groups.
2. Click on the name of a group. Click Edit.
3. For each drop-down menu, select the role to grant.
4. Click Save.

This is what the GUI should look like:

Figure 6.11 – Automation hub roles

The steps for creating and giving permissions for a group with the modules are as follows. The group_perm module sets two permissions for the Joes group:

// hub/create_groups_module.yml
---
   - name: Add group permissions
     redhat_cop.ah_configuration.ah_group_perm:
       name: Joes
       perms:
         - change_collectionremote
         - view_collectionremote
       state: present
       ah_host: https://ah.node
       ah_username: admin
       ah_password: secret123
       ah_path_prefix: galaxy
       validate_certs: false
...

The steps for creating and giving permissions for a group with the roles are as follows. The group role takes a list of groups with set permissions and applies them to the Automation hub:

// hub/create_groups_roles.yml
---
   ah_groups:
     - name: Joes
       perms:
         - change_collectionremote
         - view_collectionremote

This is the full name of the group role to apply permissions to a group:

   - redhat_cop.ah_configuration.group
...

Knowing how to assign roles, how do you go about practically assigning access?

Practically using the RBACs

With the Automation controller, users are more likely to need to access various objects in order to be able to run jobs. In the Automation hub, most users likely just need view/read access in order to see remote collections and by default can see namespaces and containers. This allows them to see what is available to use in the controller. By extension, the Automation controller itself only needs view access to the hub as well.

Only those users with the need to upload and manage namespaces and push and create execution environments need to really have extra permissions on the Automation hub. This can vary depending on how strict or permissive your organization wishes to be.

Summary

This chapter covered what roles are available to use on the Automation controller and hub. It also covered how to go about assigning those roles to users’ teams and groups.

Now that access for those using the services is covered, the next chapter will focus on the inventories of hosts, how to maintain them, and the creation of inventory plugins. These define what the Automation controller acts on.