This role is part of the Ansible Lockdown project and can be used as a standalone role or it can be used along with other Ansible roles, playbooks, or collections.


It is strongly recommended to run the role in a test environment first. There are controls that could introduce breaking changes. Check mode might not always catch these changes. The best way to confirm how the role will change your system is to fully test.


This documentation assumes that the reader has completed the steps within the

and has a good understanding of using ansible


The role requires elevated privileges and must be run as a user with sudo access. The example above uses the become option, which causes Ansible to use sudo before running tasks.


The recommended installation methods for this role are ansible-galaxy (recommended) or git.

Using ansible-galaxy

The easiest installation method is to use the ansible-galaxy command that is provided with your Ansible installation:

The general format is ansible-galaxy install git+|url to repo|, below is an example with RHEL8-CIS

ansible-galaxy install git+

The ansible-galaxy command will install the role into /etc/ansible/roles/ and this makes it easy to use with Ansible playbooks.

Using git

Start by cloning the role into a directory of your choice, this example uses ~/.ansible/roles which can be changed out for any folder. That folder needs to be empty:

To clone and create a folder with the same name as the repo:

cd ~/CIS_Roles
git clone

To clone and put the files from the repo into a specific folder, folder does need to be empty:

mkdir ~/CIS_Roles
git clone ~/CIS_Roles

Ansible looks for roles in ~/.ansible/roles by default.

If the role is cloned into a different directory, that directory must be provided with the roles_path option in ansible.cfg. The following is an example of a ansible.cfg file that uses a custom path for roles:

roles_path = /etc/ansible/roles:/home/myuser/custom/roles

With this configuration, Ansible looks for roles in /etc/ansible/roles and ~/custom/roles.

How to Use

On It’s Own

This role can be used on it’s own as a role. The file site.yml is the included file to point to. This role does not include an inventory file for hosts since that is too site specific, that will need to be managed locally. Below are examples of how to run in various scenarios

CLI - Notice the reference to site.yml

cd roles
ansible-playbook -i hosts -e '{ "rhel8stig_cat2_patch":false,"rhel8stig_cat3_patch":false }' ./RHEL8-STIG/site.yml'

Tower Steps

With Existing Playbooks

This role works well with existing playbooks. The following is an example of a basic playbook that uses this role:


- hosts: servers
  become: yes
    - role: RHEL8-CIS
        - ansible_os_family == 'RedHat'
        - ansible_distribution_major_version | version_compare('8', '=')

Variables and the Role

The role is fully customizable by setting the variables provided in the defaults/main.yml file. These variables range in usage from toggling entire sections (CIS), categories (STIG), general groups (GUI related), individual controls, localized settings, etc. There are comments around these variables that have a description of what the variable does, what the value options are, and what controls are associated with the variable. Variables are also listed in order of appearance in the execution of the role, variables used early in the are listed earlier in the file. Variables in this location are also very low in precedence, here is the official list of variable precedence. This means they are over-written very easily via extra vars

This role has been written with ease of use in mind, which means it’s written in a way that requires as little user interaction as possible. No need to modify any tasks at all!

Using and Modifying Variables Directly (defaults/main.yml)

This is the most basic way to make the change. The file has all of the available variables along with comments on what task the variable is for, a description on what the variable is, and the formatting for the value in the variable. Just update the values as needed

Modifying Variables with Extra-Vars

This is where the power of using variables via defaults/main.yml come into play. Anywhere you can use or set an extra var is place you can set these variables.

CLI In-Line setting (Set to only run STIG CAT1)

ansible-playbook -i host_file -e '{ "rhel8stig_cat2_patch":false,"rhel8stig_cat3_patch":false }' ./RHEL8-STIG/site.yml

Using Tags

Each control is tagged with various pieces of information about the control to allow for more refined use with skipping or running controls. For STIG this includes all of the ID’s, CIS has the level2 data, and both have info related to what the control relates to. For example all controls related to SSH will have the ssh tag.

STIG Example:

  - RHEL-08-040137
  - CAT2
  - CCI-001764
  - SRG-OS-000368-GPOS-00154
  - SV-244546r809339_rule
  - V-244546
  - fapolicy

CIS Example:

    - level1-server
    - level1-workstation
    - automated
    - patch
    - dhcp
    - rule_2.2.5