Overview
In my previous posts, I have shared the overview and installation procedure for the compliance operator. Once the installation is completed, we can trigger compliance scans on the cluster.
By default, compliance operator installs various profiles for different industry requirements like CIS, PCI-DSS etc. You can choose the best suited profile for the scan, depending on your requirement.
Pre-requirements
In order to trigger compliance scans, we need to have storage available in the cluster, in order for the compliance pods to store the data for longer term. If you have CSI enabled on the OpenShift cluster, persistent volumes will be provisioned dynamically. In-case the CSI isn’t available, then cluster administrator will have to create the PVs manually. You can also use local volumes as PVs using local storage operator.
Profiles
Before you trigger a scan, let’s see the different types of profiles available by default when you install the compliance operator. Run the command below to list down the installed profiles in your cluster.
$ oc get profiles.compliance
NAME AGE
ocp4-cis 2s
ocp4-cis-node 2s
ocp4-e8 2s
ocp4-moderate 2s
ocp4-moderate-node 2s
ocp4-nerc-cip 2s
ocp4-nerc-cip-node 2s
ocp4-pci-dss 2s
ocp4-pci-dss-node 2sEach profile has different rules based on the requirements. Run the command below to check the list of rules in the profiles.
Note: I have removed few lines from the output and replaced with ..
$ oc describe profiles.compliance ocp4-cis
Name: ocp4-cis
Namespace: openshift-compliance
..
Description: This profile defines a baseline that aligns to the Center for Internet Security® Red Hat OpenShift Container Platform 4 Benchmark™, V1.1. This profile includes Center for Internet Security® Red Hat OpenShift Container Platform 4 CIS Benchmarks™ content. Note that this part of the profile is meant to run on the Platform that Red Hat OpenShift Container Platform 4 runs on top of. This profile is applicable to OpenShift versions 4.6 and greater.
Id: xccdf_org.ssgproject.content_profile_cis
Kind: Profile
..
Rules:
ocp4-accounts-restrict-service-account-tokens
ocp4-accounts-unique-service-account
ocp4-api-server-admission-control-plugin-alwaysadmit
ocp4-api-server-admission-control-plugin-alwayspullimages
..
Title: CIS Red Hat OpenShift Container Platform 4 BenchmarkYou can drill down further and check the details of individual rule. Run the command below to check details about the rule.
Each rule has a description that states on what the rule is about, instructions field lays down the steps required to verify the rule and the severity depending on the impact.
$ oc describe rule ocp4-scc-limit-container-allowed-capabilities
Name: ocp4-scc-limit-container-allowed-capabilities
Namespace: openshift-compliance
..
Check Type: Platform
Description: Containers should not enable more capabilites than needed as this opens the door for malicious use. To enable only the required capabilities, the appropriate Security Context Constraints (SCCs) should set capabilities as a list in allowedCapabilities.
Id: xccdf_org.ssgproject.content_rule_scc_limit_container_allowed_capabilities
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.
Kind: Rule
..
Rationale: By default, containers run with a default set of capabilities as assigned by the Container Runtime which can include dangerous or highly privileged capabilities. Capabilities should be dropped unless absolutely critical for the container to run software as added capabilities that are not required allow for malicious containers or attackers.
Severity: medium
Title: Limit Container Capabilities
Events: <none>
Compliance Scan
Once you have reviewed the profiles and finalised which profile is required for your environment you can trigger a scan.
In order to trigger a scan, first we have to create a scansetting object. A scansetting object provides details about the storage for scan results and the schedule of the scan. As part of the operator installation, two scansetting objects default and default-auto-apply gets installed on the cluster.
You can either choose the default scansetting or create a custom scansetting based on your requirement. In this example, I have chosen the default scansetting object.
NOTE: Scansetting default-auto-apply creates auto remediations for the non-compliant rules after the scan. Unless you are certain on applying all the remediations, I suggest to choose the default scansetting first to review the non compliant rules and then apply the remediations manually.
Once we have scansetting identified, next we need to create a scansettingbinding object. This object binds the scansetting object with that of the chosen compliance profile and eventually triggers the scan.
$ vi scansettingbinding.yaml
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
name: cis-compliance
namespace: openshift-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
$ oc create -f scansettingbinding.yaml -n openshift-compliance
scansettingbinding.compliance.openshift.io/cis-compliance createdOnce the scansettingbinding object is created, required storage and compliance pods are triggered. Run the commands below to check the storage and pods.
$ oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-549a5260 1Gi RWO Delete Bound openshift-compliance/ocp4-cis-node-master default-storage 3m27s
pvc-6a04438e 1Gi RWO Delete Bound openshift-compliance/ocp4-cis-node-worker default-storage 3m39s
pvc-fceb56f4 1Gi RWO Delete Bound openshift-compliance/ocp4-cis default-storage 3m29s
$ oc get pods
NAME READY STATUS RESTARTS AGE
aggregator-pod-ocp4-cis 0/1 Completed 0 77s
aggregator-pod-ocp4-cis-node-master 0/1 Completed 0 77s
aggregator-pod-ocp4-cis-node-worker 0/1 Completed 0 77s
..
ocp4-openshift-compliance-pp-7785bff67c-xrhj6 1/1 Running 1 20h
rhcos4-openshift-compliance-pp-c84d79c7-ssdcs 1/1 Running 1 20hBased on the scansettingbinding object, operator triggers compliancesuites which in turn creates compliance scans and the check for the associated rules part of the scan. Run the commands below to check the above objects and their status.
$ oc get compliancesuite
NAME PHASE RESULT
cis-compliance DONE NON-COMPLIANT
$ oc get compliancescans
NAME PHASE RESULT
ocp4-cis DONE NON-COMPLIANT
ocp4-cis-node-master DONE NON-COMPLIANT
ocp4-cis-node-worker DONE NON-COMPLIANT
$ oc get compliancecheckresults
NAME STATUS SEVERITY
ocp4-cis-accounts-restrict-service-account-tokens MANUAL medium
ocp4-cis-accounts-unique-service-account MANUAL medium
ocp4-cis-api-server-admission-control-plugin-alwaysadmit PASS medium
ocp4-cis-api-server-admission-control-plugin-alwayspullimages PASS high
..
ocp4-cis-api-server-client-ca PASS medium
ocp4-cis-api-server-encryption-provider-cipher FAIL medium
ocp4-cis-api-server-encryption-provider-config FAIL mediumAs you can see the results above are NON-COMPLIANT for the scans. Also, the compliancecheckresults have status of MANUAL, PASS and FAIL.
Rules that are marked as PASS are compliant in the cluster. For the rules that have the FAIL and MANUAL status will have to be checked and remediated.
Conclusion
In the post, I have shared how to trigger a compliance scan based on the required profile and verify the scan results. In the next post we will discuss on how we can remediate the rules that are non-compliant.