Subscribe to our blog

How do you determine if your Red Hat Enterprise Linux (RHEL) infrastructure is compliant with security standards? Today, it’s entirely possible that you are using OpenSCAP to scan your RHEL hosts to find out if they meet a particular security policy. 

Unfortunately, this gets complicated fast.

Consider this situation: The security team wants to implement a specific policy that contains hundreds of rules. However, it determines that specific rules do not apply and should not be scanned. Furthermore, the policy may have several rules that apply to a particular version of a host. That same policy may have another number of rules that apply to a different version of the host.

How do you manage this, especially when hundreds or thousands of hosts are running varying versions of RHEL, with different applications requiring different libraries, dependencies, and configurations?

This blog post will walk through how Red Hat Insights can help you apply security compliance policies against multiple RHEL hosts using different versions of RHEL. We’ll also share how Red Hat Insights can help provide accurate and straightforward compliance reporting, improve the accuracy of your security posture, and more. 

How it works

There are three main steps to successfully implementing compliance through Red Hat Insights.

  1. Create and Deploy - As mentioned above, applying compliance policies to a pool of hosts is challenging since different versions of Operating Systems require different rules. 

  2. Remediate - Once hosts with rules failures are found, remediations are provided in the form of Ansible playbooks that will automatically fix the issues causing the rules to fail.

  3. Report - Red Hat Insights generates reports in the application and through exportable PDFs that provide accurate information about the state of compliance in your IT landscape. 

Create and Deploy

Let’s start by creating a policy. Then we’ll deploy it against a set of hosts. 


Figure 1

Navigate to the SCAP policies menu. Click on Create new policy.

Figure 2

We’ll configure the SCAP policy to be applied to a specific major version of RHEL. In this example, we’ll choose RHEL 8.

Once RHEL 8 is selected, the applicable policies are displayed.

 Figure 3

In this example, we’ll use the Protection Profile for General Purpose Operating Systems policy as highlighted in Figure 4.

Figure 4

Next, we can configure the details of the SCAP policy.

Figure 5

By clicking Next, we can observe the available hosts that can be added to the Protection Profile for General Purpose Operating Systems policy. 

Figure 6

For now, I will only apply the policy to one host, rhel1.local.

Now, we have to select the rules that apply to the policy. There are hundreds of different rules in the Protection Profile for General Purpose Operating Systems SCAP policy by default. Not all of these rules are desired in this use case because they may be overly restrictive to the operation of the host. 

For example, rules specify directories such as log, tmp, home, and boot (CCE-80853-5, CCE-80851-9, CCE-81044-0, CCE-83336-8 respectively) must be located on separate partitions. 

Figure 7 shows the details of the Common Configuration Enumeration (CCE) ID 80853-5.

Figure 7

It makes sense to store the /var/log directory on a separate partition to isolate the logs from the rest of the host. If logs consume more space than partitioned, remediation can be more flexible, preventing any interruption to the operation of the host. 

On the other hand, one might need to take the host offline first to change/var/log to a new partition. Regardless, this rule requires manual intervention to remediate. It may also be the case that this rule is better remediated during the initial installation and configuration of the host.

Red Hat Insights makes it easy to tailor the rules in your SCAP policy by enabling the removal or application of individual rules through the Web UI. We’ll remove CCE 80853-5 from our policy.

For the sake of simplicity, we’ll tailor our policy to include the following rules:

  1. Install firewalld Package CCE-82998-6

  2. The Chrony package is installed CCE-82874-9

  3. The Chronyd service is enabled CCE-82875-6

  4. Ensure that chronyd is running under chrony user account CCE-82879-8

  5. Verify firewalld Enabled CCE-80877-4

  6. A remote time server for Chrony is configured CCE-82873-1

Figure 8

Let’s finish creating the policy. 

We can trigger a compliance scan on the host by running insights-client -compliance or configuring a recurring job

Figure 9

Let’s see how our single host rhel1.local did. 

I’ll go to Reports to determine whether this host is compliant with our policy. We can see here that it has failed. 

Figure 10

By clicking on the policy, we can see that the host is 88% compliant. 


Figure 11

When I click on rhel1.local, I am taken to a report showing the specific rule that failed during the policy scan.


Figure 12


Expanding the rule tells us precisely what failed and why. An Ansible playbook is also available to remediate the problem.

Figure 13

I’ll do that by doing the following:

  1. Select the broken rule

  2. Click on the Remediate button

Figure 14

I’ll add this remediation to a new playbook I’ll call “fix chrony.” Since I’ve enabled push-button remediation, I can initiate remediation directly from to my host.

Figure 15


Figure 16

The report now shows the policy as 100% compliant. 


To make this example more realistic, I’ll add a few more hosts to this policy.

Figure 17

Here’s what the report looks like. 


Figure 18

As with before, I can zoom in to the host to find out what rule(s) failed.


Figure 19

I can download a PDF version of this report that shows the failed rule(s).

Figure 20

I can remediate all of the hosts with an Ansible playbook, as I did previously. If the Red Hat Ansible Automation Platform is available in your environment, you can use it to apply this remediation playbook. 


Figure 21

I’ve remediated all my hosts, and now the policy reports 100% compliance. 

Figure 22


I’ve shown a vastly simplified example of managing compliance with Insights and OpenSCAP on multiple hosts. 

In reality, this task is much more complex as the number of rules, hosts, and variations of operating system versions increases. What’s important to remember is Insights reduces the complexity of ensuring your organization is complying with a particular SCAP policy by:

  1. Making it easier to create and deploy a SCAP policy with the desired rules. Remember, not all rules are relevant to your organization, so Red Hat gives you the tools to remove the cruft easily.

  2. Automating remediation with Ansible playbooks. Insights provides customized remediation playbooks to drastically reduce the effort required to bring your IT landscape into compliance. 

  3. Providing relevant reports to inform the right people with accurate information about the state of compliance. The reports are automatically generated to save you time and effort. 

Learn more about what Red Hat Insights can do for your environment.

About the author

As a Senior Principal Technical Marketing Manager in the Red Hat Enterprise Linux business unit, Matthew Yee is here to help everyone understand what our products do. He joined Red Hat in 2021 and is based in Vancouver, Canada.

Read full bio

Browse by channel

automation icon


The latest on IT automation that spans tech, teams, and environments

AI icon

Artificial intelligence

Explore the platforms and partners building a faster path for AI

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


Explore how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the solutions that simplify infrastructure at the edge

Infrastructure icon


Stay up to date on the world’s leading enterprise Linux platform

application development icon


The latest on our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech