Red Hat Security: Linux in Physical, Virtual, and Cloud

Red Hat Ansible Automation Platform 2 includes a component called automation controller, which was called Red Hat Ansible Tower in earlier versions of Ansible Automation Platform. Automation controller provides a centralized hub to run your Ansible automation code.

Enterprise IT organizations need a way to define and embed automation workflows for other tools and processes. The organizations also need reliable and scalable automation execution, and a centralized system that supports auditing.

With automation controller, companies can standardize how automation is deployed by using a centralized location.

Automation controller provides a framework for running and managing Ansible efficiently on an enterprise scale. Automation controller maintains organization security by introducing features such as a centralized web UI for playbook management, role-based access control (RBAC), and centralized logging and auditing. You can integrate an enterprise's existing workflows and tool sets, such as enabling continuous integration and deployment, by using the automation controller REST API. Automation controller provides mechanisms to enable the centralized use and control of machine credentials and other secrets without exposing the credentials or secrets to the users of automation controller.

From a security perspective, automation controller helps you control, secure, and manage your Ansible automation at scale. You can use automation controller to control who has access to run particular playbooks and which inventories they can use or manage. You can allow users of the automation controller to use machine credentials and control who can manage them, without allowing users to transfer them or see their contents. Automation controller logs who ran what Ansible jobs on what hosts when, and what the results of those jobs were. It provides a way for you to centrally manage your Ansible inventories, to ensure that no hosts are missed.

The environment in Red Hat Ansible Automation Platform 2 decouples the automation controller control plane from its execution environment.

Automation controller uses automation execution environments instead of using the system executables, or uses the Python virtual environments. These environments are container images that you can pull from a central container registry, install on automation controller, and manage through a web UI. If needed, then you can create custom automation execution environments. After confirming that a custom automation execution environment works with your automation code, you can publish the container image to a container registry and then provide the new or updated automation execution environment to automation controller. Using the same automation execution environment helps to ensure that the automation code runs consistently on both your system and in automation controller.

Figure 2.1: Architecture of Ansible Automation Platform 2

Automation controller design provides the following features:

Automation controller runs the control plane (with the web UI and API) on the automation controller system, and runs automation execution environments on other machines that are closer to the managed systems. This design increases efficiency and scaling.

Automation controller provides a centralized location for organizations to run their Ansible Playbooks.

Several resources must exist before you can create a job template to test a playbook in automation controller.

Use the following resources to create a job template:

The automation controller dashboard provides a summary of information about hosts, inventories, and projects.

The left navigation bar provides quick access to resources, such as Projects, Inventories, Job Templates, and Jobs.

At the upper right of the interface, you can access your user profile, find the About page, view related documentation, and log out.

The dashboard contains the following sections:

Figure 2.2: Automation controller web interface

Credentials are used for authentication when launching jobs against machines, synchronizing with inventory sources, and importing project content from a version control system.

You can grant users and teams the ability to use these credentials, without exposing the credential to the user. If a user moves to a different team or leaves the organization, then you do not have to rekey all the systems just because that credential was available in automation controller.

The automation controller uses SSH to connect to remote hosts (or the Windows equivalent). To pass the key from the automation controller to SSH, the key must be decrypted before it can be written to a named pipe. The automation controller then uses that pipe to send the key to SSH (so that it is never written to disk).

If passwords are used, then the automation controller handles the request by responding directly to the password prompt and decrypting the password before writing it to the prompt.

Some credential types that automation controller uses for authentication are as follows:

Listing Credentials

Navigate to Resources → Credentials to list credentials. Automation controller displays the name and credential type for each credential.

Click the name of any credential to display credential details.

Figure 2.3: List of existing credentials

Automation controller uses project resources to provide access to Ansible Playbooks. If a project uses source control, such as Git or Subversion, then automation controller synchronizes content from the remote source control repository.

Navigate to Resources → Projects to list existing projects. Click the > icon to the left of a project name to expand the project information. You can synchronize projects that use source control from the Projects page.

Use the Revision column to assess whether your project is current. For a Git repository, the revision string matches a commit hash.

Figure 2.4: List of existing projects

To create a project, navigate to Resources → Projects and click Add.

Projects can specify a default execution environment for job templates. If the environment is not specified, then the project defaults to the execution environment that is defined for automation controller. You can choose job templates for different execution environments.

Choose a source control credential type, such as Git, specify additional settings, and then click Save.

Similar to a local inventory file or directory, you can create inventory resources within automation controller. Inventories can contain groups of hosts as well as ungrouped hosts. You can configure variables that apply to the entire inventory (similar to the all group), to a specific group (similar to using the groups_vars directory), and to a specific host (similar to using the host_vars directory). When creating a job template, you must specify an inventory resource to use. This inventory is similar to specifying the --inventory (-i) option of the ansible-navigator command.

Automation controller can contain many inventories, both static and dynamic. Inventories that contain dynamic content display the status of the most recent inventory synchronization attempt. Static inventories display Disabled in the Status column.

Figure 2.5: List of existing inventories

To create an inventory, navigate to Resources → Inventories and click Add → Add inventory. Specify a name for the inventory and click Save.

After creating the inventory, populate the inventory with groups and hosts. You can manually add the groups and hosts, or you can automatically populate them by using an existing inventory file in the project repository.

Manually Adding Groups and Hosts

To manually add a group, navigate to the Groups tab and then click Add. Enter a name for the group and then click Save.

To manually add an ungrouped host, which you can do at any time, navigate to the Hosts tab for the inventory and click Add. Enter a name for the host (often the fully qualified domain name for the host) and then click Save. To manually add a host to a group, navigate to the Groups tab for the inventory, click the group name, and then click the Hosts tab for the group. You can either associate an existing host within the inventory or add a new host to the group. When adding a new host, enter a name for the host (often the fully qualified domain name for the host) and then click Save.

The breadcrumb navigation displays the inventory name and the group name. In the following example, the serverb.lab.example.com host is added to the apac group in the Web Servers (Prod) inventory.

Figure 2.6: Adding a new host to a group

Populating Groups and Hosts by Using a Project Inventory File

If a project already contains an inventory file, then you can use the file to automatically populate groups and hosts within automation controller.

Within an existing group, navigate to the Sources tab and then click Add. Enter a name for the source and then select Sourced from a Project from the Source menu. Choose an existing project, select an inventory file that exists within the project, and then click Save.

Figure 2.7: Adding a new inventory source from a project

Within an existing group, navigate to the Sources tab and then click Start sync process for the source. A successful inventory synchronization creates the hosts and groups that are defined in the selected inventory file.

A job template is equivalent to running a playbook. Among other things, a job template includes an inventory, and might specify variables to override, or tags to either use or skip.

The Templates page lists existing templates. Expand template information by clicking the > icon to the left of any template name. Initiate a new job run by clicking Launch Template.

Figure 2.8: List of existing job templates

To create a job template, navigate to Resources → Templates and then click Add → Add job template. At a minimum, enter a name, select a project, and select a playbook. You can either choose an existing inventory or prompt for an inventory when the job template is launched. Job templates must specify necessary credentials, such as the machine credential that automation controller needs to connect to the managed hosts.

Job templates include additional optional fields. When you run a playbook with the ansible-navigator command, many of these options have corresponding command-line options. You can specify these options as part of the job template, or be prompted for customizations when the job template is launched.

When you launch a job template, automation controller uses an execution environment to run the playbook by using all the supplied information. If you configure the job template to prompt for information, such as an inventory, credentials, or variables, then automation controller prompts you for this information. Similarly, if the credentials for your job template prompt for passwords or passphrases, then automation controller prompts you for this information. You must interactively run the job templates that prompt for any information.

Navigate to Views → Jobs to review the job output. In addition to the output of playbook runs, the Jobs page displays inventory synchronization jobs and source control update jobs. Each job contains a number to show the order in which automation controller ran the job.

Expand job information by clicking the > icon to the left of any job name. Expanded details include who launched the job, which inventory was used, and which execution environment was used. Click a job name to see the full job output.

Figure 2.9: List of jobs