Automating the implementation of system-wide crypto policies with RHEL System Roles

Having properly configured and consistent cryptography settings across your Red Hat Enterprise Linux (RHEL) environment is a key part of system security. RHEL System Roles are a collection of Ansible roles and modules that are included in RHEL to help provide consistent workflows and streamline the execution of manual tasks.

The crypto_policies RHEL System Role can help you quickly and easily implement system-wide crypto policies across your RHEL environment. The crypto_policies role can also be used to check the current status of system-wide crypto policies in your environment.  

In this post, we show you how you can utilize the crypto-policies RHEL System Role to automate the configuration across your RHEL environment.  

Background

Cryptography can be complex to understand and difficult to properly implement and configure on systems. 

To make this even more challenging, the configuration of cryptography-related settings between different components in RHEL, such as the Apache HTTP Server, the SSHD server, and Kerberos, each have their own cryptography related configuration settings and syntax. 

Misconfiguration of some of these settings can leave the system vulnerable. This is why Red Hat introduced the system-wide crypto policies feature with RHEL 8. 

This functionality allows you to specify a cryptographic policy that applies to the default behavior of applications when running with the system-provided configuration. RHEL 8 includes four policies: DEFAULT, LEGACY, FUTURE, and FIPS.  For more information on these included policies, as well as a general overview of system-wide crypto policies, refer to the post about our crypto policies and using system-wide cryptographic policies documentation.  

Environment overview

In my example environment, I have a control node system named controlnode running RHEL 8 and three managed nodes: rhel8-server1, rhel8-server2, and rhel8-server3, all of which are also running RHEL 8.  

Note that system-wide crypto policies were introduced with RHEL 8, so the crypto-policies System Role does not support RHEL 7 or older systems.

My desired system-wide crypto policy configuration for my environment is:

• rhel8-server1 and rhel8-server2 should use the FUTURE policy

• rhel8-server3 should use the DEFAULT policy, with the NO-SHA1 policy modifier to disable SHA-1 in signature algorithms

I’ve already set up an Ansible service account on the four servers, named ansible, and have SSH key authentication set up so that the ansible account on controlnode can log in to each of the systems.

In addition, the ansible service account has been configured with access to the root account via sudo on each host. I’ve also installed the rhel-system-roles and ansible packages on controlnode. For more information on these tasks, refer to the Introduction to RHEL System Roles post. 

In this environment, I’m using a RHEL 8 control node, but you can also use Ansible Tower as your RHEL system role control node. Ansible Tower provides many advanced automation features and capabilities that are not available when using a RHEL control node. 

For more information on Ansible Tower and its functionality, refer to this overview page. 

Using role to gather current system-wide crypto policy status

The README.md file for the crypto_policies role contains important information about the role, including a list of available role variables and how to use them. The README.md file is available at /usr/share/doc/rhel-system-roles/crypto_policies/README.md

The README.md file notes that the role can be used to gather various information related to  system-wide crypto policy from systems, which is returned in the following variables:

• crypto_policies_active: shows the policy that is currently active

• crypto_policies_available_policies: shows a list of all base policies that are available

• crypto_policies_available_modules: shows a list of all policy modules that are available

From the controlnode system, I’ll create a new gather_info directory, and then create a playbook file at gather_info/gather_info.yml with the following content:

- name: Run crypto-policies System Role
  hosts: all
  roles:
    - redhat.rhel_system_roles.crypto_policies

- name: Show gathered information
  hosts: all
  tasks: 
    - name: Show currently active crypto-policy
      debug:
        msg: "Currently active crypto-policy: {{ crypto_policies_active }}"
    - name: Show available policies
      debug:
        msg: "Available policies: {{ crypto_policies_available_policies }}"
    - name: Show available policy modules
      debug:
        msg: "Available policy modules: {{ crypto_policies_available_modules }}"

The playbook calls the crypto_policies role, and then displays the contents of the three previously mentioned variables.  

I’ll also define a simple inventory file at gather_info/inventory.yml listing my three systems:

all:
  hosts:
    rhel8-server1:
    rhel8-server2:
    rhel8-server3:

I can then run the playbook using ansible-playbook to see the current status of the environment:

[ansible@controlnode ~]$ cd gather_info
[ansible@controlnode gather_info]$ ansible-playbook gather_info.yml -i inventory.yml 

The playbook runs and shows the the current status of the systems at the bottom of the output:

I can see that the rhel8-server1 and rhel8-server3 hosts are currently using the DEFAULT policy set, and the rhel8-server2 host is currently using the LEGACY policy. I can also see a list of available policies and policy modules available on each of the systems. 

Defining the inventory file and role variables

Next, from the controlnode host, I’ll create a new directory structure to contain the playbook that will be used to actually implement my desired system-wide crypto policies configuration.

[ansible@controlnode ~]$ mkdir -p crypto_policies/group_vars

These directories will be used as follows:

• crypto_policies directory will contain the playbook and the inventory file.

• crypto_policies/group_vars will define Ansible group variables that will apply to the groups of hosts that were defined in the inventory file.

I’ll create an inventory file at crypto_policies/inventory.yml that will list and group the hosts with the following content:

all:
  children:
    future_policy:
      hosts:
        rhel8-server1:
        rhel8-server2:
    default_policy_no_sha1:
      hosts:
        rhel8-server3:

This inventory lists the three hosts, and groups them into two groups:

• future_policy group contains the rhel8-server1 and rhel8-server2 hosts.

• default_policy_no_sha1 group contains the rhel8-server3 host.

 

If using Ansible Tower as your control node, this Inventory can be imported into Red Hat Ansible Automation Platform via an SCM project (example Github or Gitlab) or using the awx-manage Utility as specified in the documentation.

The previously referenced crypto_policies README.md file has information on the available role variables that can be used with the crypto_policies role.  

In summary:

• crypto_policies_policy: Is used to specify the desired system-wide crypto policy that should be implemented. This can be a base policy, or a base policy along with a module.  

• crypto_policies_reload: Controls if the role should force the reload of some of the daemons affected by the system-wide crypto policies. This defaults to true. 

• crypto_policies_reboot_ok: It is recommended to reboot hosts after changing their policy. This variable defaults to false, however if it is set to true, the role will automatically reboot the managed nodes when needed.

I’ll create a file that will define variables for the systems listed in the future_policy Ansible inventory group by creating a file at crypto_policies/group_vars/future_policy.yml. This file will contain the following content, which specifies that hosts in this group should use the FUTURE policy:

crypto_policies_policy: FUTURE

I’ll also create a file to define variables for the system listed in the default_policy_no_sha1 Ansible inventory group by creating a file at crypto_policies/group_vars/default_policy_no_sha1.yml. 

This file will contain the following content, which specifies that hosts in this group should use the DEFAULT policy along with the NO-SHA1 module.

crypto_policies_policy: DEFAULT:NO-SHA1

Creating the playbook

The next step is creating the playbook file at crypto_policies/crypto_policies.yml with the following content:

- name: Run crypto-policies System Role
  hosts: all
  roles:
    - redhat.rhel_system_roles.crypto_policies

- name: Show if reboot is needed
  hosts: all
  tasks: 
    - name: Show reboot is needed
      debug:
        msg: "Reboot is needed to apply changes"
      when: crypto_policies_reboot_required | d(false)

The first task calls the crypto_policies role for all of the systems listed in the Ansible inventory.  

The next task, Show if reboot is needed, displays a message that a “reboot is needed to apply changes” for each system that the role detects needs a reboot. This is determined based on the crypto_policies_reboot_required variable that the role returns. Later on when we run the playbook, we can decide if we would like to have the role automatically reboot the hosts if needed or not.  

If you are using Ansible Tower as your control node, you can import this Ansible playbook into Red Hat Ansible Automation Platform by creating a Project, following the documentation provided here. 

It is very common to use Git repos to store Ansible playbooks. Ansible Automation Platform stores automation in units called Jobs which contain the playbook, credentials and inventory. Create a Job Template following the documentation here. 

Running the playbook without automatically rebooting hosts

At this point, everything is in place, and I’m ready to run the playbook. 

If you are using Ansible Tower as your control node, you can launch the job from the Tower Web interface. For this demonstration, I’m using a RHEL control node and will run the playbook from the command line. I’ll use the cd command to move into the crypto_policies directory, and then use the ansible-playbook command to run the playbook. 

In this first example, the crypto_policies_reboot_ok variable is not set, and defaults to false, so the systems will not automatically reboot. Instead, the second task of the playbook will show a message if a reboot is needed to apply the configuration changes.  

[ansible@controlnode ~]$ cd crypto_policies
[ansible@controlnode crypto_policies]$ ansible-playbook crypto_policies.yml  -i inventory.yml  -b

I specify that the crypto_policies.yml playbook should be run, that it should escalate to root (the -b flag), and that the inventory.yml file should be used as my Ansible inventory (the -i flag). 

After the playbook completes, I verified that there were no failed tasks, and also note that it shows that a reboot is needed on all three of the hosts to apply the system-wide crypto policy changes.  

Running the playbook with automatic host reboots

Alternatively, I could have run the playbook with the crypto_policies_reboot_ok variable enabled. In this case, if the role detects that any of the hosts need to be rebooted to apply the system-wide crypto policies changes, they will automatically be rebooted.

This option should be used with extreme care and only when the hosts the role is running on are in a maintenance window where reboots will not impact the operational environment.  

To enable the crypto_policies_reboot_ok variable, I can use the -e parameter on the ansible-playbook command to set the variable to true:

[ansible@controlnode crypto_policies]$ ansible-playbook crypto_policies.yml  -i inventory.yml  -b -e crypto_policies_reboot_ok=true

If needed, the systems will be rebooted as the playbook runs.  

Validating the configuration

To validate that my desired system-wide crypto policies configuration was implemented, I can go back to the gather_info directory and run the previously created gather_info.yml playbook:

[ansible@controlnode ~]$ cd gather_info
[ansible@controlnode gather_info]$ ansible-playbook gather_info.yml -i inventory.yml

The playbook runs, and near the bottom of the output, it shows that my desired system-wide crypto policies were properly configured for the three systems:

Conclusion

We offer many RHEL system roles that can help automate other important aspects of your RHEL environment. To explore additional roles, review the list of available RHEL System Roles and start managing your RHEL servers in a more efficient, consistent and automated manner today. 

Want to learn more about Red Hat Ansible Automation Platform? Check out our e-book, "The automated enterprise: Unify people and processes." 

.boxed { border: 1px solid black ; }