--- title: Using the oc-compliance plugin --- # Using the oc-compliance plugin {#using-oc-compliance-plug-in} Although the Compliance Operator automates many of the checks and remediations for the cluster, an administrator can use the `oc-compliance` plugin to perform the full process of bringing a cluster into compliance by interacting with the Compliance Operator API and other components. ## Installing the oc-compliance plugin {#installing-oc-compliance_oc-compliance-plug-in-understanding} You can install the `oc-compliance` plugin to simplify compliance operations from the command line. **Procedure** - Extract the `oc-compliance` image to get the `oc-compliance` binary: ```terminal $ 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/ ``` ```terminal {title="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 {#fetching-raw-results_oc-compliance-plug-in-understanding} An administrator or auditor can review the complete detailed results of a scan as created by the OpenSCAP tool. These results contain more details than what is contained in the `ComplianceCheckResult` custom resource (CR). 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** 1. Fetch the results from the PV by running the following command: ```terminal $ oc compliance fetch-raw -o ``` where: - `` can be either `scansettingbinding`, `compliancescan` or `compliancesuite`, depending on which of these objects the scans were launched with. - `` is the name of the binding, suite, or scan object to gather the ARF file for, and `` is the local directory to place the results. For example: ```terminal $ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/ ``` ```terminal {title="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 ``` 2. View the list of files in the directory: ```terminal $ ls /tmp/ocp4-cis-node-master/ ``` ```terminal {title="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 ``` 3. Extract the results: ```terminal $ 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 ``` 4. View the extracted results: ```terminal $ ls resultsdir/worker-scan/ ``` ```terminal {title="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 {#re-running-scans_oc-compliance-plug-in-understanding} 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. Rerunning a scan with the Compliance Operator requires the use of an annotation on the scan object. However, with the `oc-compliance` plugin you can rerun a scan with a single command. **Procedure** - Rerun the scans for the `ScanSettingBinding` object named `my-binding` by running the following command: ```terminal $ oc compliance rerun-now scansettingbindings my-binding ``` ```terminal {title="Example output"} Rerunning scans from 'my-binding': ocp4-cis Re-running scan 'openshift-compliance/ocp4-cis' ``` ## Using ScanSettingBinding custom resources {#using-scan-setting-bindings_oc-compliance-plug-in-understanding} 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. Although 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: ```terminal $ oc compliance bind [--dry-run] -N [-S ] [..] ``` - 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: ```terminal $ oc get profile.compliance -n openshift-compliance ``` ```terminal {title="Example output"} NAME AGE VERSION ocp4-cis 3h49m 1.9.0 ocp4-cis-1-9 3h49m 1.9.0 ocp4-cis-node 3h49m 1.9.0 ocp4-cis-node-1-9 3h49m 1.9.0 ocp4-e8 3h49m ocp4-high 3h49m Revision 4 ocp4-high-node 3h49m Revision 4 ocp4-high-node-rev-4 3h49m Revision 4 ocp4-high-rev-4 3h49m Revision 4 ocp4-moderate 3h49m Revision 4 ocp4-moderate-node 3h49m Revision 4 ocp4-moderate-node-rev-4 3h49m Revision 4 ocp4-moderate-rev-4 3h49m Revision 4 ocp4-nerc-cip 3h49m ocp4-nerc-cip-node 3h49m ocp4-pci-dss 3h49m 4.0.0 ocp4-pci-dss-3-2 3h49m 3.2.1 ocp4-pci-dss-4-0 3h49m 4.0.0 ocp4-pci-dss-node 3h49m 4.0.0 ocp4-pci-dss-node-3-2 3h49m 3.2.1 ocp4-pci-dss-node-4-0 3h49m 4.0.0 ocp4-stig 3h49m V2R3 ocp4-stig-node 3h49m V2R3 ocp4-stig-node-v2r3 3h49m V2R3 ocp4-stig-v2r3 3h49m V2R3 rhcos4-e8 3h49m rhcos4-high 3h49m Revision 4 rhcos4-high-rev-4 3h49m Revision 4 rhcos4-moderate 3h49m Revision 4 rhcos4-moderate-rev-4 3h49m Revision 4 rhcos4-nerc-cip 3h49m rhcos4-stig 3h49m V2R3 rhcos4-stig-v2r3 3h49m V2R3 ``` ```terminal $ oc get scansettings -n openshift-compliance ``` ```terminal {title="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: ```terminal $ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node ``` ```terminal {title="Example output"} Creating ScanSettingBinding my-binding ``` After 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 {#printing-controls_oc-compliance-plug-in-understanding} You can view a report of the compliance standards and controls that a given profile satisfies. Compliance standards are generally organized into a the following hierarchy: - 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 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: ```terminal $ oc compliance controls profile ocp4-cis-node ``` ```terminal {title="Example output"} +-----------+----------+ | FRAMEWORK | CONTROLS | +-----------+----------+ | CIS-OCP | 1.1.1 | + +----------+ | | 1.1.10 | + +----------+ | | 1.1.11 | + +----------+ ... ``` ## Fetching compliance remediation details {#fetching-compliance-remediation-details_oc-compliance-plug-in-understanding} The Compliance Operator provides remediation objects that are used to automate the changes required to make the cluster compliant. You can use the `fetch-fixes` subcommand to help you understand exactly which configuration remediations are used. The `fetch-fixes` extracts the remediation objects from a profile, rule, or `ComplianceRemediation` object into a directory for you to inspect. > [!WARNING] > 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. **Procedure** 1. View the remediations for a profile: ```terminal $ oc compliance fetch-fixes profile ocp4-cis -o /tmp ``` ```terminal {title="Example output"} No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 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 ``` > [!NOTE] > 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: ```terminal $ head /tmp/ocp4-api-server-audit-log-maxsize.yaml ``` ```terminal {title="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: ```terminal $ oc get complianceremediations -n openshift-compliance ``` ```terminal {title="Example output"} NAME STATE ocp4-cis-api-server-encryption-provider-cipher NotApplied ocp4-cis-api-server-encryption-provider-config NotApplied ``` ```terminal $ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp ``` ```terminal {title="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: ```terminal $ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml ``` ```terminal {title="Example output"} apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: encryption: type: aescbc ``` ## Viewing ComplianceCheckResult object details {#viewing-compliance-remediation-details_oc-compliance-plug-in-understanding} When scans are finished running, `ComplianceCheckResult` objects are created for the individual scan rules. You can use the `view-result` subcommand to provide a human-readable output of the `ComplianceCheckResult` object details. **Procedure** - Run: ```terminal $ oc compliance view-result ocp4-cis-scheduler-no-bind-address ``` **Additional resources** {._additional-resources} - [Understanding the Compliance Operator](/openshift-docs-markdown/security/compliance_operator/co-concepts/compliance-operator-understanding#understanding-compliance-operator)