Bug 2077916
Summary: | ocp4-cis-scc-limit-container-allowed-capabilities should be MANUAL rule as all the others scc rules | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Pamela Escorza <pescorza> |
Component: | Compliance Operator | Assignee: | Vincent Shen <wenshen> |
Status: | CLOSED ERRATA | QA Contact: | xiyuan |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.6 | CC: | jhrozek, lbragsta, mrogers, suprs, wenshen, xiyuan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Cause: The ocp4-cis-scc-limit-container-allowed-capabilities rule was previously marked a failed rule, primarily because it requires knowledge about the SCC rules in the deployment.
Consequence: The rule always reported as failed, when it should be reported as manual.
Fix: Consume updated compliance operator and content.
Result: The result of running the rule more accurately reflects what users should do, which is to review SCC and make sure they're appropriate for their environment.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-07-14 12:40:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pamela Escorza
2022-04-22 15:11:17 UTC
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 |