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.
![Figure 1. Figure 1.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image5_34.png.webp?itok=lJiDob1E)
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:
![Figure 2. Figure 2.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image2_70.png.webp?itok=2lNIDf_7)
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.
![](/rhdc/managed-files/styles/wysiwyg_float/private/Icon-Red_Hat-Info-A-Red-RGB.png.webp?itok=MnQ1qln4)
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.
![Figure 3. Figure 3.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image1_98_0.png.webp?itok=vkBmruPl)
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:
![Figure 4. Figure 4.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image3_49_0.png.webp?itok=HoD0Wx1C)
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 ; }
Sobre o autor
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).
Navegue por canal
Automação
Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes
Inteligência artificial
Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente
Nuvem híbrida aberta
Veja como construímos um futuro mais flexível com a nuvem híbrida
Segurança
Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias
Edge computing
Saiba quais são as atualizações nas plataformas que simplificam as operações na borda
Infraestrutura
Saiba o que há de mais recente na plataforma Linux empresarial líder mundial
Aplicações
Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações
Programas originais
Veja as histórias divertidas de criadores e líderes em tecnologia empresarial
Produtos
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Red Hat Cloud Services
- Veja todos os produtos
Ferramentas
- Treinamento e certificação
- Minha conta
- Suporte ao cliente
- Recursos para desenvolvedores
- Encontre um parceiro
- Red Hat Ecosystem Catalog
- Calculadora de valor Red Hat
- Documentação
Experimente, compre, venda
Comunicação
- Contate o setor de vendas
- Fale com o Atendimento ao Cliente
- Contate o setor de treinamento
- Redes sociais
Sobre a Red Hat
A Red Hat é a líder mundial em soluções empresariais open source como Linux, nuvem, containers e Kubernetes. Fornecemos soluções robustas que facilitam o trabalho em diversas plataformas e ambientes, do datacenter principal até a borda da rede.
Selecione um idioma
Red Hat legal and privacy links
- Sobre a Red Hat
- Oportunidades de emprego
- Eventos
- Escritórios
- Fale com a Red Hat
- Blog da Red Hat
- Diversidade, equidade e inclusão
- Cool Stuff Store
- Red Hat Summit