CyberSecurity / Kubernetes / OpenShift

Red Hat OpenShift Compliance Operator – Compliance Scans

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    2s

Each 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 Benchmark

You 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 created

Once 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        20h

Based 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     medium

As 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.

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Tags: compliance operator · compliance scans · openshift container platform · openshift4

Comments