Managing security for many systems can be challenging. When new threats or issues are discovered, you might need to ensure that all the systems are configured or provisioned correctly.

Many administrators use automation to ensure that work is applied consistently and correctly to all machines under their care, and to speed up the correct deployment of security remediation.

A good automation solution must be able to deploy and provision systems from scratch. Administrators must be able to run automated tasks on a system that is already configured, and either confirm that it is already correctly configured and do nothing, or change that system to ensure that it is correctly configured.

You can use many tools for this purpose. In this course, you use Red Hat Ansible Automation Platform to address security issues. Using Ansible in a security context offers several advantages:

When your security policy is defined in Ansible, scanning and remediation of site-wide security policies can be integrated into other automated processes. Instead of being an afterthought, security is an integral part of everything that is deployed.

To run Ansible Playbooks, install the automation content navigator (ansible-navigator) on your control node and download an execution environment. Hosts that Ansible manages do not require the ansible-navigator tool to be installed; you need to install this tool only on the control node that you run Ansible Playbooks from.

Python 3.8 or later must be installed on the control node before you install the ansible-core package.

You must have a valid Red Hat Ansible Automation Platform subscription to install the automation content navigator on your control node.

If you activated Simple Content Access for your organization in the Red Hat Customer Portal, then you do not need to attach the subscription to your system.

[root@controlnode ~]# subscription-manager repos \
--enable ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms

[root@controlnode ~]# dnf install ansible-navigator

[user@controlnode ~]$ ansible-navigator --version
ansible-navigator 3.4.1

[user@controlnode ~]$ podman login registry.redhat.io
Username: your-registry-username
Password: your-registry-password
Login Succeeded!

[user@controlnode ~]$ ansible-navigator images
  Image                 Tag     Execution environment   Created         Size
0│ee-supported-rhel9    latest  True                    10 days ago     1.63 GB


^b/PgUp page up   ^f/PgDn page down   ↑↓ scroll   esc back   [0-9] goto   :help

Ansible is a cross-platform solution that can manage Linux hosts, Microsoft Windows systems, and even managed networking devices. This course focuses on configuring Linux managed hosts.

One benefit of Ansible is that a special agent does not need to be installed on managed hosts. The Ansible control node connects to managed hosts by using a standard network protocol to ensure that the systems are in the specified state.

Depending on how the control node connects to the managed hosts, and which modules are run on them, managed hosts might have the following requirements:

When configuring authentication and privilege escalation in Ansible, you have several options based on your policies and needs. A common method involves using SSH public key authentication to connect as a non-privileged user and using sudo to escalate privileges to the root user.

You can choose one of the following options to configure the Ansible user with sudo access. For the first option, configure sudo to require the Ansible user to enter their password to escalate privileges. The default configuration of the /etc/sudoers file permits sudo access for any member of the wheel group, so you might add the Ansible user to that group.

For the second option, add a rule to explicitly allow sudo access for a user. For example, by creating a file named /etc/sudoers.d/ansible-testuser that includes the following line, you allow the ansible-testuser user to use sudo to run any command as any user after they enter their password to authenticate.

ansible-testuser  ALL=(ALL) ALL

You can allow the Ansible user to run sudo without entering a password. This approach is less secure, but it might be more convenient than requiring a password. For example, you could set up /etc/sudoers.d/user to allow the ansible-testuser user to use sudo to run any command as any user without further authentication, in this way:

ansible-testuser  ALL=(ALL) NOPASSWD:ALL

The following example contains one play with a single task:

---
- name: Configure important user consistently
  hosts: server1.example.com
  tasks:
    - name: Newbie exists with UID 4000
      ansible.builtin.user:
        name: newbie
        uid: 4000
        state: present

A playbook is a text file in YAML format, and is normally saved with the .yml extension. The playbook uses indentation with space characters to indicate the structure of its data. Although YAML does not place strict requirements on how many spaces are used for the indentation, two main rules apply:

You can also add blank lines for readability.

A playbook usually begins with a line that consists of three dashes (---) to indicate the start of the document. A playbook might end with three dots (...) to indicate the end of the document, although in practice this boundary marker is often omitted.

Between those markers, the playbook is defined as a list of plays. An item in a YAML list starts with a single dash followed by a space. For example, a YAML list might appear as follows:

- apple
- orange
- grape

The play itself is a collection of key-value pairs. Keys in the same play must have the same indentation. The following example shows a YAML snippet with three keys. The first two keys have single values. The third key has a list of three items as a value.

---
  name: just an example
  hosts: webservers
  tasks:
    - first
    - second
    - third

The initial example play has three keys: name, hosts, and tasks. These keys all have the same indentation.

The first line of the example play starts with a dash and a space (to indicate that the play is the first item of a list), and then the first key, name. The name key associates an arbitrary string with the play as a label that identifies the purpose of the play. The name key, though optional, is recommended because it helps to document your playbook. This name key is especially useful when a playbook contains multiple plays.

- name: Configure important user consistently

The second key in the play is a hosts key, which specifies the hosts that the play's tasks are run against. The hosts key takes a host pattern as a value, such as the names of managed hosts or groups in the inventory.

  hosts: server1.example.com

Finally, the last key in the play is tasks, whose value specifies a list of tasks to run for this play. This example has a single task, which runs the ansible.builtin.user module with specific arguments (to ensure that the newbie user exists and has UID 4000).

  tasks:
    - name: newbie exists with UID 4000
      ansible.builtin.user:
        name: newbie
        uid: 4000
        state: present

The tasks key is the part of the play that lists, in order, the tasks to be run on the managed hosts. Each task in the list is itself a collection of key-value pairs.

In this example, the only task in the play has two keys:

The following output is another example of a tasks key with multiple tasks, where each task uses the ansible.builtin.service module to ensure that a service starts at boot:

  tasks:
    - name: Web server is enabled
      ansible.builtin.service:
        name: httpd
        enabled: true

    - name: NTP server is enabled
      ansible.builtin.service:
        name: chronyd
        enabled: true

    - name: Postfix is enabled
      ansible.builtin.service:
        name: postfix
        enabled: true

Plays use modules to run tasks. Hundreds of modules are written for different purposes. You can usually find a tested, special-purpose module that does what you need, often as part of the default automation execution environment.

Ansible Content Collections distribute multiple types of Ansible content, such as playbooks, modules, documentation, and more.

The ansible-core package provides a single Ansible Content Collection named ansible.builtin. These modules are always available to you. Visit https://docs.ansible.com/ansible/latest/collections/ansible/builtin/ for a list of modules in the ansible.builtin collection.

In addition, the default automation execution environment that ansible-navigator uses in Red Hat Ansible Automation Platform 2.4, ee-rhel9-supported, includes several other Ansible Content Collections.

You can browse these collections by running the ansible-navigator collections command. In the interactive UI, you can type a colon (:) followed by the line number of a collection to get more information about it, including the list of modules and other Ansible content that it provides. You can do the same thing with the line number of a module to get documentation about that module. Press Esc to go back to the preceding list.

  Name               Version Shadowed Type	 Path
 0│amazon.aws         6.0.1   False    contained /usr/share/ansible/collections▒
 1│ansible.builtin    2.15.4  False    contained /usr/lib/python3.9/site-packag▒
 2│ansible.controller 4.4.2   False    contained /usr/share/ansible/collections▒
 3│ansible.netcommon  5.1.1   False    contained /usr/share/ansible/collections▒
 4│ansible.network    2.0.0   False    contained /usr/share/ansible/collections▒
 5│ansible.posix      1.5.4   False    contained /usr/share/ansible/collections▒

Modules are named by using fully qualified collection names (FQCNs). The same name can then be used for different modules in two Ansible Content Collections without causing conflicts. For example, the copy module from the ansible.builtin Ansible Content Collection has ansible.builtin.copy as its FQCN.

The default output from the ansible-navigator run command does not provide detailed task execution information. The -v option provides additional information, with up to four levels.

Before executing a playbook, it is good practice to validate its syntax. You can use the ansible-navigator run --syntax-check command to validate the syntax of a playbook. The following example shows the successful syntax validation of a playbook:

[user@controlnode playdemo]$ ansible-navigator run \
-m stdout webserver.yml --syntax-check
playbook: /home/user/playdemo/webserver.yml

When syntax validation fails, a syntax error is reported. The output also includes the approximate location of the syntax issue in the playbook.

You can use the --check option to run a playbook in check mode, which executes a playbook without altering your systems. In check mode, Ansible reports which changes would have occurred if the playbook was executed, but it does not make any changes to managed hosts.

The following example shows the check mode of a playbook that contains a single task for ensuring that the latest version of the httpd package is installed on a managed host. In this case, the dry run reports that the task would make a change on the managed host.

[user@controlnode playdemo]$ ansible-navigator run \
-m stdout webserver.yml --check

PLAY [Play to set up web server] ***********************************************

TASK [Gathering Facts] *********************************************************
ok: [server1.example.com]

TASK [Latest httpd version installed] ******************************************
changed: [server1.example.com]

PLAY RECAP *********************************************************************
server1.example.com    : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0