Different people using an automation controller installation require different levels of access. Some might need to run existing job templates against a preconfigured inventory of machines. Others need to be able to modify particular inventories, job templates, and playbooks, or need access to change anything in the automation controller installation.

The automation controller interface has a built-in administrative user, admin, which has superuser access to the entire automation controller configuration. Setting up user accounts for each person makes it easier to manage individual access to inventories, credentials, projects, and job templates.

Users are assigned roles, which in turn grant permissions. These permissions specify who can view, change, or delete an object in automation controller. Role-based Access Controls (RBAC) manage roles. To manage roles collectively, grant them to a team. A team is a collection of users. All users in a team inherit the team’s roles.

Roles determine whether users and teams can view, use, change, or delete objects, such as inventories and projects.

An automation controller organization is a logical collection of teams, projects, and inventories. All users must belong to an organization.

One of the benefits of implementing an automation controller server is sharing Ansible content, including Ansible Content Collections, roles, and automation execution environments, across departmental or functional boundaries within an enterprise. For example, an operations group of an organization might already have a custom automation execution environment for provisioning production versions of web, database, and application servers. The developers group can use the same environment to provision servers for their development environment. Automation controller makes it easier for different users and groups to use existing content collections, roles, and automation execution environments.

For large deployments, however, it can be useful to categorize large numbers of users, teams, projects, and inventories under one umbrella organization. Certain departments might not deploy to specific inventories of hosts, or run certain playbooks. By using organizations, you can configure a collection of users and teams to work with only those automation controller resources that they are expected to use.

The automation controller installation process creates a Default organization. You can create additional organizations in the web UI using the following procedure:

By default, the automation controller installer creates an admin user account with full control of the automation controller installation. You can use this account to log in to the web UI and create additional users.

The three user types in automation controller are System Administrator, System Auditor, and Normal User.

Use the following procedure to create new users:

To modify user details, use the same fields you used to create the user.

Users inherit specific roles from their organization based on their user type. You can assign additional roles to grant permissions to view, use, or change other automation controller objects. An organization is itself one of these objects.

Many roles provide access to an organization, and you can assign multiple roles to users and teams. The lecture on managing users efficiently with teams describes additional organization roles.

The following sections describe organization roles that are inherited based on user type.

Only the organization can manage the roles that a user has within that organization. You cannot manage roles by editing the user. To manage access to an organization, use the following procedure:

The Access page displays a list of users who have been granted roles for the organization.

To remove an existing role for a user, find the user’s row and then click the X in the role name box.

Figure 2.3: Organization roles assigned to users

To add a user to an organization, or to add additional roles to an existing user within the organization, use the following procedure: