Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Using the oc-compliance plugin

Although the Compliance Operator automates many of the checks and remediations for the cluster, the full process of bringing a cluster into compliance often requires administrator interaction with the Compliance Operator API and other components. The oc-compliance plugin makes the process easier.

Installing the oc-compliance plugin

Procedure

  1. Extract the oc-compliance image to get the oc-compliance binary:

    $ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/
    Example output
    W0611 20:35:46.486903   11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.

    You can now run oc-compliance.

Fetching raw results

When a compliance scan finishes, the results of the individual checks are listed in the resulting ComplianceCheckResult custom resource (CR). However, an administrator or auditor might require the complete details of the scan. The OpenSCAP tool creates an Advanced Recording Format (ARF) formatted file with the detailed results. This ARF file is too large to store in a config map or other standard Kubernetes resource, so a persistent volume (PV) is created to contain it.

Procedure

  • Fetching the results from the PV with the Compliance Operator is a four-step process. However, with the oc-compliance plugin, you can use a single command:

    $ oc compliance fetch-raw <object-type> <object-name> -o <output-path>

  • <object-type> can be either scansettingbinding, compliancescan or compliancesuite, depending on which of these objects the scans were launched with.

  • <object-name> is the name of the binding, suite, or scan object to gather the ARF file for, and <output-path> is the local directory to place the results.

    For example:

    $ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/
    Example output
    Fetching results for my-binding scans: ocp4-cis, ocp4-cis-node-worker, ocp4-cis-node-master
Fetching raw compliance results for scan 'ocp4-cis'.......
The raw compliance results are available in the following directory: /tmp/ocp4-cis
Fetching raw compliance results for scan 'ocp4-cis-node-worker'...........
The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-worker
Fetching raw compliance results for scan 'ocp4-cis-node-master'......
The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-master

View the list of files in the directory:

$ ls /tmp/ocp4-cis-node-master/
Example output
ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2

Extract the results:

$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml

View the results:

$ ls resultsdir/worker-scan/
Example output
worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2
worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2

Re-running scans

Although it is possible to run scans as scheduled jobs, you must often re-run a scan on demand, particularly after remediations are applied or when other changes to the cluster are made.

Procedure

  • Rerunning a scan with the Compliance Operator requires use of an annotation on the scan object. However, with the oc-compliance plugin you can rerun a scan with a single command. Enter the following command to rerun the scans for the ScanSettingBinding object named my-binding:

    $ oc compliance rerun-now scansettingbindings my-binding
    Example output
    Rerunning scans from 'my-binding': ocp4-cis
Re-running scan 'openshift-compliance/ocp4-cis'

Using ScanSettingBinding custom resources

When using the ScanSetting and ScanSettingBinding custom resources (CRs) that the Compliance Operator provides, it is possible to run scans for multiple profiles while using a common set of scan options, such as schedule, machine roles, tolerations, and so on. While that is easier than working with multiple ComplianceSuite or ComplianceScan objects, it can confuse new users.

The oc compliance bind subcommand helps you create a ScanSettingBinding CR.

Procedure

  1. Run:

    $ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]

    • If you omit the -S flag, the default scan setting provided by the Compliance Operator is used.

    • The object type is the Kubernetes object type, which can be profile or tailoredprofile. More than one object can be provided.

    • The object name is the name of the Kubernetes resource, such as .metadata.name.

    • Add the --dry-run option to display the YAML file of the objects that are created.

      For example, given the following profiles and scan settings:

      $ oc get profile.compliance -n openshift-compliance
      Example output
      NAME              AGE
ocp4-cis          9m54s
ocp4-cis-node     9m54s
ocp4-e8           9m54s
ocp4-moderate     9m54s
ocp4-ncp          9m54s
rhcos4-e8         9m54s
rhcos4-moderate   9m54s
rhcos4-ncp        9m54s
rhcos4-ospp       9m54s
rhcos4-stig       9m54s
      $ oc get scansettings -n openshift-compliance
      Example output
      NAME                 AGE
default              10m
default-auto-apply   10m

  2. To apply the default settings to the ocp4-cis and ocp4-cis-node profiles, run:

    $ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node
    Example output
    Creating ScanSettingBinding my-binding

    Once the ScanSettingBinding CR is created, the bound profile begins scanning for both profiles with the related settings. Overall, this is the fastest way to begin scanning with the Compliance Operator.

Printing controls

Compliance standards are generally organized into a hierarchy as follows:

  • A benchmark is the top-level definition of a set of controls for a particular standard. For example, FedRAMP Moderate or Center for Internet Security (CIS) v.1.6.0.

  • A control describes a family of requirements that must be met in order to be in compliance with the benchmark. For example, FedRAMP AC-01 (access control policy and procedures).

  • A rule is a single check that is specific for the system being brought into compliance, and one or more of these rules map to a control.

  • The Compliance Operator handles the grouping of rules into a profile for a single benchmark. It can be difficult to determine which controls that the set of rules in a profile satisfy.

Procedure

  • The oc compliance controls subcommand provides a report of the standards and controls that a given profile satisfies:

    $ oc compliance controls profile ocp4-cis-node
    Example output
    +-----------+----------+
| FRAMEWORK | CONTROLS |
+-----------+----------+
| CIS-OCP   | 1.1.1    |
+           +----------+
|           | 1.1.10   |
+           +----------+
|           | 1.1.11   |
+           +----------+
...

Fetching compliance remediation details

The Compliance Operator provides remediation objects that are used to automate the changes required to make the cluster compliant. The fetch-fixes subcommand can help you understand exactly which configuration remediations are used. Use the fetch-fixes subcommand to extract the remediation objects from a profile, rule, or ComplianceRemediation object into a directory to inspect.

Procedure

  1. View the remediations for a profile:

    $ oc compliance fetch-fixes profile ocp4-cis -o /tmp
    Example output
    No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' (1)
No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled'
No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup'
Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml
No fixes to persist for rule 'ocp4-api-server-audit-log-path'
No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa'
No fixes to persist for rule 'ocp4-api-server-auth-mode-node'
No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac'
No fixes to persist for rule 'ocp4-api-server-basic-auth'
No fixes to persist for rule 'ocp4-api-server-bind-address'
No fixes to persist for rule 'ocp4-api-server-client-ca'
Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml
Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml
    1 The No fixes to persist warning is expected whenever there are rules in a profile that do not have a corresponding remediation, because either the rule cannot be remediated automatically or a remediation was not provided.

  2. You can view a sample of the YAML file. The head command will show you the first 10 lines:

    $ head /tmp/ocp4-api-server-audit-log-maxsize.yaml
    Example output
    apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  maximumFileSizeMegabytes: 100

  3. View the remediation from a ComplianceRemediation object created after a scan:

    $ oc get complianceremediations -n openshift-compliance
    Example output
    NAME                                             STATE
ocp4-cis-api-server-encryption-provider-cipher   NotApplied
ocp4-cis-api-server-encryption-provider-config   NotApplied
    $ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp
    Example output
    Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

  4. You can view a sample of the YAML file. The head command will show you the first 10 lines:

    $ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml
    Example output
    apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aescbc

Use caution before applying remediations directly. Some remediations might not be applicable in bulk, such as the usbguard rules in the moderate profile. In these cases, allow the Compliance Operator to apply the rules because it addresses the dependencies and ensures that the cluster remains in a good state.

Viewing ComplianceCheckResult object details

When scans are finished running, ComplianceCheckResult objects are created for the individual scan rules. The view-result subcommand provides a human-readable output of the ComplianceCheckResult object details.

Procedure

  • Run:

    $ oc compliance view-result ocp4-cis-scheduler-no-bind-address