Enforce Compliance
In a recent article about how to write a SELinux Compliance Policy you learned how to use CloudForms’ and ManageIQ’s capability to perform compliance checks. This article goes one step further: Instead of just reporting compliance or non-compliance of a given virtual machine, we use the power of Ansible to enforce compliance.
This example builds on the Compliance and Control policy described in the mentioned article and it is recommended to read it first.
Compliance Policies
Enterprises often have rules and regulations about system compliance. This could include a specific baseline configuration, for example hardening rules. It could also include other requirements, like backup and monitoring has to be configured, a proper license has to be available (particularly with proprietary software) and more. Compliance checks in CloudForms and ManageIQ can bundle these requirements into policy profiles.
If one or more of the requirements is not met, actions can be triggered. The most obvious and most simple to implement is to mark the system as being “non compliant”.
Compliance policies can also trigger other actions, including running an Ansible Playbook or perform a custom method, which allows us to run our own (Ruby) Method as an action.
Ansible Playbook as an Action
Coming back to the problem at hand, an error in the SELinux configuration, Ansible would be the logical tool choice to fix the system configuration. There are two options available to run Ansible Playbooks from CloudForms or ManageIQ:
-
Embedded Ansible: Since CloudForms 4.5 and ManageIQ Fine there a built in native capability to run Ansible Playbooks
-
Ansible Tower: Since CloudForms 4.1 and ManageIQ Darga we can run Ansible Playbook from Ansible Tower
Running Ansible Playbook from Tower
A GitLab repository with CloudForms Ansible Playbooks optimized for the usage with CloudForms and ManageIQ has to be added to Tower first. This repository contains a Playbooks called “selinux-enforcing” which makes sure the SELinux modus is set to “Enforcing”.
After adding the repository and running an initial sync, a Job Template has to be created, which runs the previously imported Playbook. Make sure the following requirements are met:
-
Job Template Name: make sure you use the name “Fix SELinux”. If you want to use another name, the Compliance Policy imported later, has to be adjusted accordingly
-
Check “Prompt on Launch” for the Limit parameter: During Playbook execution CloudForms or ManageIQ will set the limit parameter dynamically to the correct value to ensure the Playbook is only executed on the non compliant system and not the entire inventory. If this box is not checked (enabled), the limit parameter set by CloudForms or ManageIQ will be ignored by Ansible Tower - and the Playbook will be executed on the entire inventory
Next we force an update of the Ansible Tower inventory. Navigate to Automation, Ansible Tower and Explorer. Select your Tower Provider and click on Configuration, Refresh Relationships and Power State. Such a refresh is executed in the background and can take a minute or two. Eventually the new Job Template should show up in the accordion on the left.
Create a new Action
To trigger an execution of an Ansible Playbook from a Control or Compliance Policy, we first have to create a new Action. Navigate to Control, Explorer. In the accordion on the left, click on Actions and from there Configuration, Add a new Action.
-
Description: Fix SELinux
-
Action Type: Invoke a Custom Automation
-
Message: create
-
Request: ansible_tower_job
-
Attribute 1: job_template_name
-
Value 1: Fix SELinux
Note: The Name “Fix SELinux” has to match the name of the Job Template definition in Ansible Tower, or the Action will fail.
Running Ansible Playbook natively
If you want to use the native support to run Ansible Playbooks, it’s important to make sure the Embedded Ansible Role is enabled. Without this Role properly running, Ansible Playbooks can not be executed and it is not even possible to add an Ansible Playbook Repository. A good article summarizing the how to Debug Ansible Automation inside Red Hat CloudForms has just been published by my buddy Victor.
After ensuring the Role is properly configured, add the CloudForms Ansible Playbooks repository found on GitLab.
This blog post is not going into details on how to do this. I already created a lab called Getting well with CloudForms which covers the embedded Ansible capabilities.
Updating the Compliance Policy
To use the previously created Action in the Compliance Policy, navigate to Control, Explorer first. Then navigate to the Compliance Policy and the respective event. Add the Action you created in the previous step to the “Order of Actions if ANY Conditions are False” list.
I uploaded an example VM-Security-Profile-with-Ansible-Action on Github.
Testing and Conclusion
You should now have a combination of the following policies:
-
A Control Policy “Run SmartState” which will schedule a Smart State Analysis scan in the background if a VM is powered on or reset
-
A Control Policy “Check Compliance” which will trigger a Compliance Check every time a VM completed Smart State Analysis
-
A Compliance Policy “Check SELinux Policy” which verifies SELinux is configured in Enforcing mode, and if not, marks the VM as non compliant and runs an Ansible Playbook to fix the configuration error
To do a test run, you can either power on a VM, or “Perform Smart State Analysis” from the VM Configuration menu.