When scanning an environment using a profile that includes the file-permissions-var-log-kube-audit rule, like PCI-DSS, you'll see an inconsistent result regardless of how many time you run the scan.

Recreated the CO 1.1.0 and OpenShift 4.14 and 4.12.

Always

1. Create a scan for PCI-DSS

cat << EOF | oc apply -n openshift-compliance -f -
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: pci-dss-scan
profiles:
  - name: ocp4-pci-dss
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
  - name: ocp4-pci-dss-node
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
EOF


2. See there is one inconsistent ComplianceCheckResult

If you inspect the file permissions on the failing node, there is a termination.log with 644 permissions instead of 600. Master nodes that pass the check do not have 644 permissions.

$ oc debug node/ip-10-0-139-76.ec2.internal
Temporary namespace openshift-debug-dnxkr is created for debugging node...
Starting pod/ip-10-0-139-76ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.139.76
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# ls -l /var/log/kube-apiserver/.*
-rw-r--r--.  1 root root    0 Jul 26 18:04 /var/log/kube-apiserver/.lock
-rw-r--r--.  1 root root    0 Jul 26 18:04 /var/log/kube-apiserver/.terminating/var/log/kube-apiserver/.:
total 237508
-rw-------. 1 root root 104857367 Jul 26 18:41 audit-2023-07-26T18-41-45.360.log
-rw-------. 1 root root 104857266 Jul 26 19:14 audit-2023-07-26T19-14-29.601.log
-rw-------. 1 root root  30886132 Jul 26 19:21 audit.log
-rw-r--r--. 1 root root         4 Jul 26 18:04 termination.log
 

One of the master nodes fails the check, causing an INCONSISTENT result.

All master nodes should pass the check, resulting in an overall PASS when the results are aggregated together.