Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Managed Node Configuration

Ansible Automation Platform is an agentless technology that relies on making a remote connection to the devices it manages, called managed nodes, to run automation tasks.

This chapter provides recommendations on improving the security posture of the managed nodes automated by Ansible Automation Platform, including the remote connections between Ansible Automation Platform and the managed nodes.

Note that managed node configuration can vary significantly based on factors such as operating system, compliance profiles, configuration, and organizational policies.

Any recommendations on managed node configuration presented here must be thoroughly tested and reviewed before implementation to ensure that they meet organizational policies and requirements.

The following section provides guidance for Red Hat Enterprise Linux (RHEL) managed nodes, but the concepts may be applicable to other Linux distributions as well.

Examples are provided for manual configuration of RHEL managed nodes. These steps can also be automated with Ansible Automation Platform, or they can be added to a Standard Operating Environment (SOE) or "golden image" created with a tool such as the Red Hat Insights image builder.

Ansible Automation Platform can be configured to use various users or accounts for connecting to managed nodes.

This guide recommends creating a single, dedicated service account for this purpose. This service account must be a local account on each managed node to ensure automation jobs continue to run, even if an external authentication mechanism experiences an outage. This recommendation applies unless organizational policy mandates centrally managed service accounts. The service account must be clearly named to indicate its purpose, for instance, ansible or aapsvc.

The remainder of this section uses "ansible" as the assumed name for a local service account in its examples.

The local service account is configured in the following manner:

  • It is granted sufficient privileges to run any automation job required.
  • It is limited to SSH key authentication only. No password authentication is allowed.

  • Access is only granted to connections made from the Ansible Automation Platform {ControllerNames}s and execution nodes.

    Note

    To execute tasks in an Ansible playbook or job template as a user other than the service account, use the become and become_user keywords. Connecting to the managed node as a different user is not necessary.

  • The useradd command can be used to create a local service account. For example: 
sudo useradd ansible \
    --system --create-home \
    --comment "Ansible Automation Platform service account"
Copy to Clipboard Toggle word wrap

The service account requires sufficient privileges to run any current or future automation job on the managed node. This section describes the use of sudo, though other privilege escalation methods are available.

Since Ansible Automation Platform defaults to using the ansible.builtin.sudo become plugin on Linux-based managed nodes, the service account must be permitted to run any command on the RHEL managed node using the sudo command.

To configure this, use the following procedure:

Procedure

  1. Create the file /etc/sudoers.d/ansible, and include the following content: 

    # Rules for the ansible service account
ansible ALL=(ALL) NOPASSWD: ALL
    Copy to Clipboard Toggle word wrap

  2. Set restrictive permissions on the file:

    sudo chmod 600 /etc/sudoers.d/ansible`

  3. Verify the file uses the proper syntax:

    sudo visudo -cf /etc/sudoers.d/ansible

The service account must not be permitted to use password authentication with SSH connections to the managed node.

Use the following procedure to configure the SSH daemon:

Procedure

  1. Create the file /etc/sshd/sshd_config.d/60-ansible.conf, and include the following content: 

    # sshd config applied to the ansible service account
Match User ansible
	PasswordAuthentication no
Match all
    Copy to Clipboard Toggle word wrap

  2. Verify that the file uses the proper syntax:

    sudo sshd -t

  3. Restart the SSH daemon

    sudo systemctl restart sshd.service

Given that password authentication is prohibited, at least one SSH public key must be appended to the service account’s authorized_keys file (typically located at /home/ansible/.ssh/authorized_keys).

These public keys must correspond with the private keys used to establish Machine credentials in Ansible Automation Platform, as these credentials facilitate connections to the RHEL managed nodes.

This guide advocates for a single service account for connections to managed RHEL nodes, but this does not mean using a single SSH key across all nodes is required. In larger organizations, individual teams managing RHEL servers can generate their own machine credentials within Ansible Automation Platform. Teams can then add the corresponding keys to the authorized keys file on their specific RHEL servers. This approach ensures consistent access to managed nodes organization-wide by using a common service account, while enabling each team to independently manage the credentials for their assigned nodes.

To restrict remote login access to connections originating from the Ansible Automation Platform automation controller and execution nodes and ensure the service account is exclusively used by Ansible Automation Platform, use the following procedure:

Procedure

  1. Use the FQDNs of your automation controller and execution nodes to add the following content to the /etc/security/access.conf file, using the FQDNs of your controller nodes and execution nodes: 

    # allow the ansible service account to log in from local sources and
# the hybrid controller or execution nodes, and deny all other sources
+:ansible:LOCAL controller1.example.com controller2.example.com en1.example.com
-:ansible:ALL
    Copy to Clipboard Toggle word wrap

  2. Enable the with-pamaccess feature in the current authselect profile. All authselect profiles included by default with RHEL have this feature.

    sudo authselect enable-feature with-pamaccess

3.1.2. Compliance profile considerations
Copy link

In many environments, you can use Ansible Automation Platform to manage systems where security controls have been applied to managed RHEL nodes to meet the requirements of a compliance profile such as CIS, PCI/DSS, the DISA STIG, or similar. The following sections detail the specific set of security controls that must be modified for Ansible Automation Platform to manage the RHEL nodes properly in such environments.

3.1.2.1. Fapolicyd on managed RHEL nodes
Copy link

When an Ansible Automation Platform job runs against a RHEL managed node, most tasks are executed by copying Python code to the managed node and then executing it locally. The job will fail if the fapolicyd service is enabled on the managed node, because the default set of rules that come with RHEL prevents this Python code from running.

To prevent this issue from occurring, use one of the following methods:

  • Option 1: Set the fapolicyd service to permissive mode
  • Option 2: Create custom fapolicyd rules

The fapolicyd service can be set to "permissive" mode, meaning that it only logs fapolicyd rule violations, rather than enforcing them.

To configure permissive mode for fapolicyd, use the following procedure:

Procedure

  1. Edit the file /etc/fapolicyd/fapolicyd.conf, and set "permissive = 1".
  2. Restart the fapolicy service by running systemctl restart fapolicyd.service.

In environments where this configuration might not meet a required compliance profile or local policy, discuss waiving the relevant security control with your security auditor.

3.1.2.3. Option 2: Create custom fapolicyd rules
Copy link

Where the fapolicyd service must enforce its rules, consider crafting a custom set of rules to permit Ansible Automation Platform to execute its Python code.

The following example procedure treats the "ansible" service account as a trusted entity and enables it to execute content in the local Ansible temporary directory (by default, $HOME/.ansible/tmp).

Procedure

  1. Create the file /etc/fapolicy/rules.d/50-ansible.rules with the following content:

    allow perm=any uid=ansible trust=1 : dir=/home/ansible/.ansible/tmp/

  2. Restart the fapolicyd service:

    sudo systemctl restart fapolicyd.service

This example rule might require modification to work with any other fapolicyd rules that exist on the managed RHEL nodes, and must be thoroughly tested and approved by your security auditor before being put into production.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat