175 lines
6.8 KiB
Plaintext
175 lines
6.8 KiB
Plaintext
---
|
||
title: Retrieving raw compliance results
|
||
exercise: 6
|
||
date: '2024-09-02'
|
||
tags: ['openshift','compliance','nist-800-53','scanning']
|
||
draft: false
|
||
authors: ['default']
|
||
summary: "Need to integrate results with another platform? No problem!"
|
||
---
|
||
|
||
Often organisations will have dedicated software for managing governance, risk and compliance or need to provide results to external auditors. In these situations while the dashboards within Red Hat Advanced Cluster Security, or `ComplianceCheckResult` objects in the OpenShift APIServer are helpful, what we really need to do is integrate these results into our third party compliance management platform or pass results in a standardised format to third parties.
|
||
|
||
In this exercise, we'll briefly step through retrieving raw compliance results, in the well known **Asset Reporting Framework** (ARF) format.
|
||
|
||
The Asset Reporting Format is a data model to express the transport format of information about assets, and the relationships between assets and reports. The standardized data model facilitates the reporting, correlating, and fusing of asset information throughout and between organizations. ARF is vendor and technology neutral, flexible, and suited for a wide variety of reporting applications.
|
||
|
||
For more details on the format specification refer to https://www.nist.gov/publications/specification-asset-reporting-format-11
|
||
|
||
|
||
## 6.1 - Understanding raw result storage
|
||
|
||
When the Compliance Operator runs a scan, raw results are stored in a `PersistentVolume`. The following `oc` command shows the mapping `PersistentVolume` name for a given scan name.
|
||
|
||
Let's use our scan name that we set up previously, `daily-nist-800-53-moderate`:
|
||
|
||
```bash
|
||
oc get --namespace openshift-compliance compliancesuites daily-nist-800-53-moderate --output json | jq '.status.scanStatuses[].resultsStorage'
|
||
```
|
||
|
||
We should see results showing the name of each `PersistentVolume` for each profile that was scanned, below is an example:
|
||
|
||
```json
|
||
{
|
||
"name": "ocp4-moderate",
|
||
"namespace": "openshift-compliance"
|
||
}
|
||
{
|
||
"name": "ocp4-moderate-node-master",
|
||
"namespace": "openshift-compliance"
|
||
}
|
||
{
|
||
"name": "ocp4-moderate-node-worker",
|
||
"namespace": "openshift-compliance"
|
||
}
|
||
```
|
||
|
||
We can view the details of these `PersistentVolumes` as follows:
|
||
|
||
|
||
```bash
|
||
oc get pvc --namespace openshift-compliance ocp4-moderate
|
||
```
|
||
|
||
|
||
## 6.2 - Retrieving results from a volume
|
||
|
||
Let's retrieve some specific results files from a volume by mounting the volume into a pod, and then using `oc` to copy the volume contents to our highside ssh host.
|
||
|
||
We can create a pod using the `rhel8/support-tools` additional image that was mirrored into our disconnected environment.
|
||
|
||
> Note: Note the use of the pinned sha256 image digest below rather than standard image tags, this is a requirement of the mirroring process.
|
||
|
||
```bash
|
||
cat << EOF | oc --namespace openshift-compliance apply --filename -
|
||
apiVersion: "v1"
|
||
kind: Pod
|
||
metadata:
|
||
name: pv-extract
|
||
spec:
|
||
containers:
|
||
- name: pv-extract-pod
|
||
image: registry.redhat.io/rhel8/support-tools@sha256:ab42416e9e3460f6c6adac4cf09013be6f402810fba452ea95bd717c3ab4076b
|
||
command: ["sleep", "3000"]
|
||
volumeMounts:
|
||
- mountPath: "/ocp4-moderate-scan-results"
|
||
name: ocp4-moderate-scan-vol
|
||
volumes:
|
||
- name: ocp4-moderate-scan-vol
|
||
persistentVolumeClaim:
|
||
claimName: ocp4-moderate
|
||
EOF
|
||
```
|
||
|
||
> Note: Spawning a pod that mounts the `PersistentVolume` will keep the claim as `Bound`. If the volume’s storage class in use has permissions set to `ReadWriteOnce`, the volume is only mountable by one pod at a time. You must delete the pod upon completion, or it will not be possible for the Operator to schedule a pod and continue storing results in this location.
|
||
|
||
With the volume mounted we can copy the results out to our machine:
|
||
|
||
```bash
|
||
mkdir /mnt/high-side-data/compliance-results
|
||
oc cp pv-extract:/ocp4-moderate-scan-results --namespace openshift-compliance .
|
||
```
|
||
|
||
After the copy has completed we should delete our helper pod to unbind the volume:
|
||
|
||
```bash
|
||
oc delete pod pv-extract --namespace openshift-compliance
|
||
```
|
||
|
||
|
||
## 6.3 - Reviewing raw result files
|
||
|
||
Now that we have a copy of the raw result files, let's see what they look like.
|
||
|
||
Starting with an `ls -lah` in our highside terminal we can see each scan result is stored in a numbered directory, yours should look similar to the example below:
|
||
|
||
```bash
|
||
drwxr-xr-x. 5 lab-user lab-user 42 Sep 1 20:35 .
|
||
drwxr-xr-x. 7 lab-user lab-user 4.0K Sep 1 20:28 ..
|
||
drwxr-xr-x. 2 lab-user lab-user 52 Sep 1 20:35 0
|
||
drwxr-xr-x. 2 lab-user lab-user 52 Sep 1 20:35 1
|
||
drwxr-xr-x. 2 lab-user lab-user 6 Sep 1 20:35 lost+found
|
||
```
|
||
|
||
If we take a look at one of the specific directories with `ls -lah compliance-results/1/` we'll see an archive file:
|
||
|
||
```bash
|
||
-rw-r--r--. 1 lab-user lab-user 251K Sep 1 20:35 ocp4-moderate-api-checks-pod.xml.bzip2
|
||
```
|
||
|
||
Let's drop into that directory and extract it now to take a look at the contents, run the commands below in your highside ssh terminal:
|
||
|
||
> Note: If you get an error from the `bunzip2` command below you may need to first install it with `sudo yum install --yes bzip2`.
|
||
|
||
```bash
|
||
cd /mnt/high-side-data/compliance-results/1
|
||
bunzip2 ocp4-moderate-api-checks-pod.xml.bzip2
|
||
mv ocp4-moderate-api-checks-pod.xml.bzip2.out ocp4-moderate-api-checks-pod.xml
|
||
ls -lah
|
||
```
|
||
|
||
Now we're getting somewhere, we can see we have `.xml` file. Let's take a quick peek at the contents:
|
||
|
||
```bash
|
||
head ocp4-moderate-api-checks-pod.xml
|
||
```
|
||
|
||
You should see an xml document snippet similar to the example below:
|
||
|
||
```xml
|
||
<core:relationships xmlns:arfvocab="http://scap.nist.gov/specifications/arf/vocabulary/relationships/1.0#">
|
||
<core:relationship type="arfvocab:createdFor" subject="xccdf1">
|
||
<core:ref>collection1</core:ref>
|
||
</core:relationship>
|
||
<core:relationship type="arfvocab:isAbout" subject="xccdf1">
|
||
<core:ref>asset0</core:ref>
|
||
</core:relationship>
|
||
</core:relationships>
|
||
```
|
||
|
||
|
||
## 6.4 - Generating reports with openscap tooling
|
||
|
||
To finish off this exercise let's go one step further and use OpenSCAP tooling to generate an html based report we can open in our vnc Firefox browser.
|
||
|
||
Run the commands below in your high side terminal, we'll start by installing the `openscap-scanner` package.
|
||
|
||
```bash
|
||
sudo yum install -y openscap-scanner
|
||
```
|
||
|
||
One the tooling is installed let's generate the report:
|
||
|
||
```bash
|
||
oscap xccdf generate report ocp4-moderate-api-checks-pod.xml > report.html
|
||
```
|
||
|
||
So far we've done all this on our high side terminal. We need to get this report artifact to our low side server where our Firefox vnc session is running, let's copy it out now:
|
||
|
||
```bash
|
||
exit # Return to low side server
|
||
rsync highside:/mnt/high-side-data/compliance-results/1/report.html /home/lab-user/Downloads/report.html
|
||
```
|
||
|
||
Finally - we can open up our report in our web based Firefox vnc session! Once you've reviewed the report you can move on to exercise 7 🚀
|