I agree this is slightly irritating. Normally, openscap which the CO is running under the hood is trying to read /etc/hostname, but that's not present on RHCOS.

That said, the node that was scanned is present as an annotation:
Namespace:    openshift-compliance
Labels:       compliance.openshift.io/scan-name=workers-cis
              complianceoperator.openshift.io/scan-result=
Annotations:  compliance-remediations/processed:
              compliance.openshift.io/scan-error-msg:
              compliance.openshift.io/scan-result: NON-COMPLIANT
              openscap-scan-result/node: ip-10-0-140-145.eu-north-1.compute.internal
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Data
====
exit-code:
----
2
results:
----
<?xml version="1.0" encoding="UTF-8"?>
<TestResult xmlns="http://checklists.nist.gov/xccdf/1.2" id="xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_cis-node" start-time="2021-06-09T11:06:02+00:00" end-time="2021-06-09T11:06:03+00:00" version="0.1.57" test-s>
          <benchmark href="/content/ssg-ocp4-ds.xml" id="xccdf_org.ssgproject.content_benchmark_OCP-4"/>
          <title>OSCAP Scan Result</title>
          <profile idref="xccdf_org.ssgproject.content_profile_cis-node"/>
          <target>Unknown</target>
          <target-facts>
            <fact name="urn:xccdf:fact:identifier" type="string">chroot:///host</fact>
            <fact name="urn:xccdf:fact:scanner:name" type="string">OpenSCAP</fact>
            <fact name="urn:xccdf:fact:scanner:version" type="string">1.3.4</fact>
          </target-facts>

Would using this annotation help the customer?

There are some environment variables that can tune things like the name (https://github.com/OpenSCAP/openscap/blob/maint-1.3/docs/manual/manual.adoc#list-of-accepted-environment-variables) I'll try checking if the node name can be set this way.

OK, the variables would probably not help..there is OSCAP_EVALUATION_TARGET which would set urn:xccdf:fact:identifier under target-facts for example:

          <target>Unknown</target>
          <target-facts>
            <fact name="urn:xccdf:fact:identifier" type="string">chroot:///host</fact>
            <fact name="urn:xccdf:fact:scanner:name" type="string">OpenSCAP</fact>
            <fact name="urn:xccdf:fact:scanner:version" type="string">1.3.4</fact>
          </target-facts>

using this variable we would set the urn:xccdf:fact:identifier to whatever we want, perhaps the node name. Would that help the customer?

Acc. to the standard <target> should hold the FQDN or hostname (if FQDN is not available). We can adjust the scanner to place OSCAP_EVALUATION_TARGET if it is set and hostname is absent (i.e. in place of 'unknown'). What do you think about this idea?

BTW is there any other way to get the hostname of the RHCOS node besides reading it from /etc/hostname?

(In reply to Evgeny Kolesnikov from comment #11)
> Acc. to the standard <target> should hold the FQDN or hostname (if FQDN is
> not available). We can adjust the scanner to place OSCAP_EVALUATION_TARGET
> if it is set and hostname is absent (i.e. in place of 'unknown'). What do
> you think about this idea?
> 
> BTW is there any other way to get the hostname of the RHCOS node besides
> reading it from /etc/hostname?

/proc/sys/kernel/hostname is what you can take a look at in absence of /etc/hostname.

But I suspect for OCP environment, especially public clouds, the hostname is not as relevant as the node name (which is the 'name' attribute of the 'Node' API object in kubernetes). The reason simply being that it's the node name, not the host name that the admin uses when interacting with the cluster nodes. So having the hostname settable by whoever is orchestrating the scan would be more useful.

Although poking at another source would be a big improvement over 'unknown', no argument about that.

btw if you think it would be more in line with the standard to put the hostname into <target> and the nodeName into one of the facts, that would also work I guess..

One thing bothers me, why the hostname of the node can't be equal to nodename of the node? Why it is not if it can?

(In reply to Evgeny Kolesnikov from comment #14)
> One thing bothers me, why the hostname of the node can't be equal to
> nodename of the node? Why it is not if it can?

It can, but it doesn't have to be. In the end, I don't mind which one we use that much. As I said in comment #13, using the hostname for the target and putting nodeName into the facts (which can be done using an env variable already) is OK.

PR: https://github.com/openshift/compliance-operator/pull/688

[Bug_Verification]

Looks good to me. Now, the complianceScan XCCDF format result shows relevant nodeName in target element and urn:xccdf:fact:identifier for node checks.

Verified On:
4.9.0-0.nightly-2021-09-23-142241 + compliance-operator.v0.1.41


$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.0-0.nightly-2021-09-23-142241   True        False         3h48m   Cluster version is 4.9.0-0.nightly-2021-09-23-142241

$ oc get csv
NAME                             DISPLAY                            VERSION   REPLACES   PHASE
compliance-operator.v0.1.41      Compliance Operator                0.1.41               Succeeded
elasticsearch-operator.5.2.2-7   OpenShift Elasticsearch Operator   5.2.2-7              Succeeded

$ oc get pods -w
NAME                                              READY   STATUS    RESTARTS       AGE
compliance-operator-c769749d5-8pjgm               1/1     Running   1 (175m ago)   176m
ocp4-openshift-compliance-pp-64dbd7c98f-dwhdz     1/1     Running   0              175m
rhcos4-openshift-compliance-pp-66575dc885-lb9vh   1/1     Running   0              175m

$ oc create -f - <<EOF
> apiVersion: compliance.openshift.io/v1alpha1
> kind: ScanSettingBinding
> metadata:
>   name: cis-compliance
> profiles:
>   - name: ocp4-cis-node
>     kind: Profile
>     apiGroup: compliance.openshift.io/v1alpha1
>   - name: ocp4-cis
>     kind: Profile
>     apiGroup: compliance.openshift.io/v1alpha1
> settingsRef:
>   name: default
>   kind: ScanSetting
>   apiGroup: compliance.openshift.io/v1alpha1
> EOF
scansettingbinding.compliance.openshift.io/cis-compliance created



$ oc get pods 
NAME                                                    READY   STATUS      RESTARTS     AGE
aggregator-pod-ocp4-cis                                 0/1     Completed   0            2m48s
aggregator-pod-ocp4-cis-node-master                     0/1     Completed   0            2m58s
aggregator-pod-ocp4-cis-node-worker                     0/1     Completed   0            2m28s
compliance-operator-c769749d5-8pjgm                     1/1     Running     1 (3h ago)   3h1m
ocp4-cis-api-checks-pod                                 0/2     Completed   0            3m30s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-0-pod    0/2     Completed   0            3m31s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-1-pod    0/2     Completed   0            3m31s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-2-pod    0/2     Completed   0            3m30s
ocp4-openshift-compliance-pp-64dbd7c98f-dwhdz           1/1     Running     0            3h
openscap-pod-a66b87aad261fa091e6791413811e72bb0d232f9   0/2     Completed   0            3m28s
openscap-pod-b4a2f4787f65c320edd9a57a0cfbb9c7bfbc24f7   0/2     Completed   0            3m28s
openscap-pod-f64ff847b6f0c2421082c3eee0268d1815f0b70e   0/2     Completed   0            3m28s
rhcos4-openshift-compliance-pp-66575dc885-lb9vh         1/1     Running     0            3h

$ oc get compliancescan 
NAME                   PHASE   RESULT
ocp4-cis               DONE    NON-COMPLIANT
ocp4-cis-node-master   DONE    NON-COMPLIANT
ocp4-cis-node-worker   DONE    NON-COMPLIANT

$ oc get suite
NAME             PHASE   RESULT
cis-compliance   DONE    NON-COMPLIANT

$ oc get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                       STORAGECLASS      REASON   AGE
pvc-1727589d-2aa1-44d0-9046-e9d00c8852fa   1Gi        RWO            Delete           Bound    openshift-compliance/ocp4-cis               managed-premium            4m27s
pvc-4a254d2e-0d81-4908-8e68-3fa23458aa98   1Gi        RWO            Delete           Bound    openshift-compliance/ocp4-cis-node-worker   managed-premium            4m25s
pvc-8f7a719e-9571-47fe-8b25-f18fb690ab7f   1Gi        RWO            Delete           Bound    openshift-compliance/ocp4-cis-node-master   managed-premium            4m27s

$ oc get pvc
NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
ocp4-cis               Bound    pvc-1727589d-2aa1-44d0-9046-e9d00c8852fa   1Gi        RWO            managed-premium   4m40s
ocp4-cis-node-master   Bound    pvc-8f7a719e-9571-47fe-8b25-f18fb690ab7f   1Gi        RWO            managed-premium   4m49s
ocp4-cis-node-worker   Bound    pvc-4a254d2e-0d81-4908-8e68-3fa23458aa98   1Gi        RWO            managed-premium   4m33s


$ oc get cm
NAME                                                    DATA   AGE
compliance-operator-lock                                0      3h5m
kube-root-ca.crt                                        1      3h5m
ocp4-cis-api-checks-pod                                 3      6m48s
ocp4-cis-node-master-openscap-container-entrypoint      1      7m46s
ocp4-cis-node-master-openscap-env-map                   4      7m46s
ocp4-cis-node-master-openscap-env-map-platform          3      7m46s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-0-pod    3      6m52s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-1-pod    3      6m55s
ocp4-cis-node-master-pdhamdhe0924-8nndq-master-2-pod    3      6m52s
ocp4-cis-node-worker-openscap-container-entrypoint      1      7m50s
ocp4-cis-node-worker-openscap-env-map                   4      7m50s
ocp4-cis-node-worker-openscap-env-map-platform          3      7m49s
ocp4-cis-openscap-container-entrypoint                  1      7m38s
ocp4-cis-openscap-env-map                               4      7m38s
ocp4-cis-openscap-env-map-platform                      3      7m38s
openscap-pod-a66b87aad261fa091e6791413811e72bb0d232f9   3      6m53s
openscap-pod-b4a2f4787f65c320edd9a57a0cfbb9c7bfbc24f7   3      6m56s
openscap-pod-f64ff847b6f0c2421082c3eee0268d1815f0b70e   3      6m57s
openshift-service-ca.crt                                1      3h5m


$ oc get nodes
NAME                                         STATUS   ROLES    AGE     VERSION
pdhamdhe0924-8nndq-master-0                  Ready    master   4h11m   v1.22.0-rc.0+af080cb
pdhamdhe0924-8nndq-master-1                  Ready    master   4h11m   v1.22.0-rc.0+af080cb
pdhamdhe0924-8nndq-master-2                  Ready    master   4h11m   v1.22.0-rc.0+af080cb
pdhamdhe0924-8nndq-worker-centralus1-bkhnz   Ready    worker   4h2m    v1.22.0-rc.0+af080cb
pdhamdhe0924-8nndq-worker-centralus2-9xh96   Ready    worker   3h46m   v1.22.0-rc.0+af080cb
pdhamdhe0924-8nndq-worker-centralus3-6qzwq   Ready    worker   4h2m    v1.22.0-rc.0+af080cb


$ for pod in $(oc get cm -lcompliance.openshift.io/scan-name=ocp4-cis-node-master,complianceoperator.openshift.io/scan-result= --no-headers |awk '{print $1}'); do echo -e "\n\n <<<<< Check target in raw result for '$pod' >>>>>"; oc extract cm/$pod --confirm; grep "target>pdhamdhe\|identifier" results; done


 <<<<< Check target in raw result for 'ocp4-cis-node-master-pdhamdhe0924-8nndq-master-0-pod' >>>>>
exit-code
results
warnings
          <target>pdhamdhe0924-8nndq-master-0</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-master-0</fact>


 <<<<< Check target in raw result for 'ocp4-cis-node-master-pdhamdhe0924-8nndq-master-1-pod' >>>>>
exit-code
results
warnings
          <target>pdhamdhe0924-8nndq-master-1</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-master-1</fact>


 <<<<< Check target in raw result for 'ocp4-cis-node-master-pdhamdhe0924-8nndq-master-2-pod' >>>>>
exit-code
results
warnings
          <target>pdhamdhe0924-8nndq-master-2</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-master-2</fact>


$ for pod in $(oc get cm -lcompliance.openshift.io/scan-name=ocp4-cis-node-worker,complianceoperator.openshift.io/scan-result= --no-headers |awk '{print $1}'); do echo -e "\n\n <<<<< Check target in raw result for '$pod' >>>>>"; oc extract cm/$pod --confirm; oc get pods $pod -oyaml |grep "nodeName"; grep "target>pdhamdhe\|identifier" results; done


 <<<<< Check target in raw result for 'openscap-pod-a66b87aad261fa091e6791413811e72bb0d232f9' >>>>>
results
warnings
exit-code
  nodeName: pdhamdhe0924-8nndq-worker-centralus1-bkhnz
          <target>pdhamdhe0924-8nndq-worker-centralus1-bkhnz</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-worker-centralus1-bkhnz</fact>


 <<<<< Check target in raw result for 'openscap-pod-b4a2f4787f65c320edd9a57a0cfbb9c7bfbc24f7' >>>>>
exit-code
results
warnings
  nodeName: pdhamdhe0924-8nndq-worker-centralus2-9xh96
          <target>pdhamdhe0924-8nndq-worker-centralus2-9xh96</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-worker-centralus2-9xh96</fact>


 <<<<< Check target in raw result for 'openscap-pod-f64ff847b6f0c2421082c3eee0268d1815f0b70e' >>>>>
exit-code
results
warnings
  nodeName: pdhamdhe0924-8nndq-worker-centralus3-6qzwq
          <target>pdhamdhe0924-8nndq-worker-centralus3-6qzwq</target>
            <fact name="urn:xccdf:fact:identifier" type="string">pdhamdhe0924-8nndq-worker-centralus3-6qzwq</fact>

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Compliance Operator bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4530