-
Bug
-
Resolution: Obsolete
-
Normal
-
None
-
4.16.0, 4.18.0
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Per clusterlogforwarders.observability.openshift.io crd link, there are three inputs - audit, application and infrastructure that are possible. e2e does have this accounted for example forward-logs.yaml
Install Red Hat OpenShift Logging with version cluster-logging.v6.2.1 provided by Red Hat
The customer created a ClusterLogForwarder CR:
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
managementState: Managed
outputs:
- splunk:
authentication:
token:
secretName: dds-splunk-hec-token
key: token
url: 'https://ospliaprod1.XYZ.com:8088'
index: test
type: splunk
name: splunk-receiver
pipelines:
- inputRefs:
- audit
- infrastructure
outputRefs:
- splunk-receiver
name: openshift-splunk-pipeline
serviceAccount:
name: openshift-splunk-pipeline-sa
logging.openshift.io was changed to observability.openshift.io/v1
Execute the scan
apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
name: onerule-debugx
namespace: openshift-compliance
spec:
scans:
- name: onerule-debug-scan
profile: xccdf_org.ssgproject.content_profile_pci-dss-4-0
content: ssg-ocp4-ds.xml
contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:75ebf09b17c6f7894742cab703023252e9e135f9eed3aca38826e12c32342d4b
rule: xccdf_org.ssgproject.content_rule_audit_log_forwarding_enabled
scanType: Platform
debug: true
nodeSelector:
node-role.kubernetes.io/worker: ""
It'll fail (when it should succeed)