Description of problem: ocp4-cis-scc-limit-container-allowed-capabilities should be MANUAL rule Hardening v1.1 should be corrected too. Version-Release number of selected component (if applicable): Compliance Operator 1.49 OCP v4 How reproducible: configure scan setting to review CIS Beanchmark profiles and verify the rules: Actual results: in a fresh new cluster: $ oc get compliancecheckresults.compliance.openshift.io ocp4-cis-scc-limit-container-allowed-capabilities NAME STATUS SEVERITY ocp4-cis-scc-limit-container-allowed-capabilities PASS medium In customer environment: ocp4-cis-scc-limit-container-allowed-capabilities FAIL medium Expected results: ocp4-cis-scc-limit-container-allowed-capabilities MANUAL medium Should be manual as Customer need to verify it's own bespoke scc
verification pass with 4.11.0-0.nightly-2022-06-30-005428 + latest co code + content from quay.io/compliance-operator/compliance-operator-content:latest Just one minor issue, when there are two manual rules in compliancesuite, does the result should show "NON-COMPLIANT"? Thanks. # oc apply -f -<<EOF > apiVersion: compliance.openshift.io/v1alpha1 > kind: TailoredProfile > metadata: > name: mod-node > spec: > title: My modified profile with manual rules > manualRules: > - name: ocp4-scc-limit-container-allowed-capabilities > rationale: platform > > description: test > EOF tailoredprofile.compliance.openshift.io/mod-node created # oc get tp NAME STATE mod-node READY # oc apply -f -<<EOF > apiVersion: compliance.openshift.io/v1alpha1 > kind: ScanSettingBinding > metadata: > name: test > profiles: > - apiGroup: compliance.openshift.io/v1alpha1 > kind: TailoredProfile > name: mod-node > settingsRef: > apiGroup: compliance.openshift.io/v1alpha1 > kind: ScanSetting > name: default > EOF scansettingbinding.compliance.openshift.io/test created test LAUNCHING NOT-AVAILABLE # oc get suite -w NAME PHASE RESULT test RUNNING NOT-AVAILABLE test RUNNING NOT-AVAILABLE test AGGREGATING NOT-AVAILABLE test AGGREGATING NOT-AVAILABLE test DONE NON-COMPLIANT test DONE NON-COMPLIANT ^C# oc get ccr NAME STATUS SEVERITY mod-node-master-scc-limit-container-allowed-capabilities MANUAL medium mod-node-worker-scc-limit-container-allowed-capabilities MANUAL medium
Currently yes. This is an issue with openscap which doesn't distinguish return-code-wise between the two states. We'd have to post-process the results ourselves. We know about the issue, but it's a lot of work and realistically all MANUAL rules are only happening in testing.
verification pass with compliance-operator.v0.1.53 + 4.11.0-rc.1 $ oc get ip NAME CSV APPROVAL APPROVED install-hksfh compliance-operator.v0.1.53 Automatic true $ oc get csv NAME DISPLAY VERSION REPLACES PHASE compliance-operator.v0.1.53 Compliance Operator 0.1.53 Succeeded elasticsearch-operator.v5.5.0 OpenShift Elasticsearch Operator 5.5.0 Succeeded $ oc apply -f -<<EOF > apiVersion: compliance.openshift.io/v1alpha1 > kind: TailoredProfile > metadata: > name: mod-node > spec: > title: My modified profile with manual rules > manualRules: > - name: ocp4-scc-limit-container-allowed-capabilities > rationale: platform > description: test > EOF tailoredprofile.compliance.openshift.io/mod-node created $ oc get tp NAME STATE mod-node READY $ cat mod.yaml apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: test profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: TailoredProfile name: mod-node settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default $ oc apply -f mod.yaml scansettingbinding.compliance.openshift.io/test created $ oc get suite -w NAME PHASE RESULT test LAUNCHING NOT-AVAILABLE test LAUNCHING NOT-AVAILABLE test RUNNING NOT-AVAILABLE test RUNNING NOT-AVAILABLE test AGGREGATING NOT-AVAILABLE test AGGREGATING NOT-AVAILABLE test DONE NON-COMPLIANT test DONE NON-COMPLIANT ^C $ oc get ccr NAME STATUS SEVERITY mod-node-master-scc-limit-container-allowed-capabilities MANUAL medium mod-node-worker-scc-limit-container-allowed-capabilities MANUAL medium $ oc get rule ocp4-scc-limit-container-allowed-capabilities -o=jsonpath={.instructions} Inspect each SCC returned from running the following command: $ oc get scc Next, examine the outputs of the following commands: $ oc describe roles --all-namespaces $ oc describe clusterroles For any role/clusterrole that reference the securitycontextconstraints resource with the resourceNames of the SCCs that do not list an explicit allowedCapabilities, examine the associated rolebindings to account for the users that are bound to the role. Review each SCC and determine that only required capabilities are either completely added as a list entry under allowedCapabilities, or that all the un-required capabilities are dropped for containers and SCCs.
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 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-2022:5537
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days