Chapter 9. Setting a custom cryptographic policy by using the crypto-policies RHEL system role

As an administrator, you can use the crypto_policies RHEL system role to quickly and consistently configure custom cryptographic policies across many different systems using the Ansible Core package.

9.1. Setting a custom cryptographic policy by using the crypto_policies system role

You can use the crypto_policies system role to configure a large number of managed nodes consistently from a single control node.

Prerequisites

Procedure

  1. Create a playbook file, for example ~/playbook.yml, with the following content:

    ---
    - name: Configure crypto policies
      hosts: managed-node-01.example.com
      tasks:
        - name: Configure crypto policies
          ansible.builtin.include_role:
            name: rhel-system-roles.crypto_policies
          vars:
            - crypto_policies_policy: FUTURE
            - crypto_policies_reboot_ok: true

    You can replace the FUTURE value with your preferred crypto policy, for example: DEFAULT, LEGACY, and FIPS:OSPP.

    The crypto_policies_reboot_ok: true setting causes the system to reboot after the system role changes the cryptographic policy.

  2. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  3. Run the playbook:

    $ ansible-playbook ~/playbook.yml
Warning

Because the FIPS:OSPP system-wide subpolicy contains further restrictions for cryptographic algorithms required by the Common Criteria (CC) certification, the system is less interoperable after you set it. For example, you cannot use RSA and DH keys shorter than 3072 bits, additional SSH algorithms, and several TLS groups. Setting FIPS:OSPP also prevents connecting to Red Hat Content Delivery Network (CDN) structure. Furthermore, you cannot integrate Active Directory (AD) into the IdM deployments that use FIPS:OSPP, communication between RHEL hosts using FIPS:OSPP and AD domains might not work, or some AD accounts might not be able to authenticate.

Note that your system is not CC-compliant after you set the FIPS:OSPP cryptographic subpolicy. The only correct way to make your RHEL system compliant with the CC standard is through the installation of the cc-config package. See the Common Criteria section in the Compliance Activities and Government Standards Knowledgebase article for a list of certified RHEL versions, validation reports, and links to CC guides hosted at the National Information Assurance Partnership (NIAP) website.

Verification

  1. On the control node, create another playbook named, for example, verify_playbook.yml:

    ---
    - name: Verification
      hosts: managed-node-01.example.com
      tasks:
        - name: Verify active crypto policy
          ansible.builtin.include_role:
            name: rhel-system-roles.crypto_policies
        - debug:
            var: crypto_policies_active
  2. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/verify_playbook.yml
  3. Run the playbook:

    $ ansible-playbook ~/verify_playbook.yml
    TASK [debug] **************************
    ok: [host] => {
        "crypto_policies_active": "FUTURE"
    }

    The crypto_policies_active variable shows the policy active on the managed node.

Additional resources

  • /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md file
  • /usr/share/doc/rhel-system-roles/crypto_policies/ directory