Getting started

The ansible-hardening role can be used along with the OpenStack-Ansible
project or as a standalone role that can be used along with other Ansible
playbooks. This documentation assumes that the reader has completed the steps
within the
Ansible installation guide.

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:

[DEFAULTS]roles_path=/etc/ansible/roles:/home/myuser/custom/roles

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

The ansible-hardening role works well with existing playbooks. The following
is an example of a basic playbook that uses the ansible-hardening role:

----name:Harden all systemshosts:allbecome:yesvars:security_enable_firewalld:nosecurity_rhel7_initialize_aide:nosecurity_ntp_servers:-1.example.com-2.example.comroles:-ansible-hardening

The variables provided in the vars section can enable, disable, or alter
configuration for various tasks in the ansible-hardening role. For more details
on the available variables, refer to the Hardening Domains (RHEL 7 STIG)
section.

Note

The role must be run as the root user or as a user with sudo access.
The example above uses the become option, which causes Ansible to use
sudo before running tasks. If the role is running as root, this option can
be changed to user:root.

Warning

It is strongly recommended to run the role in check mode (often called a
dry run) first before making any modifications. This gives the deployer
the opportunity to review all of the proposed changes before applying the
role to the system. Use the --check parameter with ansible-playbook
to use check mode.