Chapter 5. Compliance Operator

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators OperatorHub.
2. Search for the Compliance Operator, then click Install.
3. Keep the default selection of Installation mode and namespace to ensure that the Operator will be installed to the openshift-compliance namespace.
4. Click Install.

1. Navigate to the Operators Installed Operators page.
2. Check that the Compliance Operator is installed in the openshift-compliance namespace and its status is Succeeded.

1. Navigate to the Operators Installed Operators page and inspect the Status column for any errors or failures.
2. Navigate to the Workloads Pods page and check the logs in any pods in the openshift-compliance project that are reporting issues.

Procedure

1. Define a Namespace object:

   Example namespace-object.yaml

   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       openshift.io/cluster-monitoring: "true"
     name: openshift-compliance

2. Create the Namespace object:

   $ oc create -f namespace-object.yaml

3. Define an OperatorGroup object:

   Example operator-group-object.yaml

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: compliance-operator
     namespace: openshift-compliance
   spec:
     targetNamespaces:
     - openshift-compliance

4. Create the OperatorGroup object:

   $ oc create -f operator-group-object.yaml

5. Define a Subscription object:

   Example subscription-object.yaml

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: compliance-operator-sub
     namespace: openshift-compliance
   spec:
     channel: "release-0.1"
     installPlanApproval: Automatic
     name: compliance-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace

6. Create the Subscription object:

   $ oc create -f subscription-object.yaml

Verification

1. Verify the installation succeeded by inspecting the CSV file:

   $ oc get csv -n openshift-compliance

2. Verify that the Compliance Operator is up and running:

   $ oc get deploy -n openshift-compliance

Procedure

1. In the Administrator perspective of the web console, navigate to Operators Installed Operators.
2. Click the name of the Operator you want to change the update channel for.
3. Click the Subscription tab.
4. Click the name of the update channel under Channel.
5. Click the newer update channel that you want to change to, then click Save.

6. For subscriptions with an Automatic approval strategy, the update begins automatically. Navigate back to the Operators Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.

   For subscriptions with a Manual approval strategy, you can manually approve the update from the Subscription tab.

Procedure

1. In the Administrator perspective of the OpenShift Container Platform web console, navigate to Operators Installed Operators.
2. Operators that have a pending update display a status with Upgrade available. Click the name of the Operator you want to update.
3. Click the Subscription tab. Any update requiring approval are displayed next to Upgrade Status. For example, it might display 1 requires approval.
4. Click 1 requires approval, then click Preview Install Plan.
5. Review the resources that are listed as available for update. When satisfied, click Approve.
6. Navigate back to the Operators Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.

Procedure

1. Inspect the ScanSetting object by running:

   $ oc describe scansettings default -n openshift-compliance

   Example output

   Name:         default
   Namespace:    openshift-compliance
   Labels:       <none>
   Annotations:  <none>
   API Version:  compliance.openshift.io/v1alpha1
   Kind:         ScanSetting
   Metadata:
     Creation Timestamp:  2022-10-10T14:07:29Z
     Generation:          1
     Managed Fields:
       API Version:  compliance.openshift.io/v1alpha1
       Fields Type:  FieldsV1
       fieldsV1:
         f:rawResultStorage:
           .:
           f:nodeSelector:
             .:
             f:node-role.kubernetes.io/master:
           f:pvAccessModes:
           f:rotation:
           f:size:
           f:tolerations:
         f:roles:
         f:scanTolerations:
         f:schedule:
         f:showNotApplicable:
         f:strictNodeScan:
       Manager:         compliance-operator
       Operation:       Update
       Time:            2022-10-10T14:07:29Z
     Resource Version:  56111
     UID:               c21d1d14-3472-47d7-a450-b924287aec90
   Raw Result Storage:
     Node Selector:
       node-role.kubernetes.io/master:
     Pv Access Modes:
       ReadWriteOnce 1
     Rotation:  3 2
     Size:      1Gi 3
     Tolerations:
       Effect:              NoSchedule
       Key:                 node-role.kubernetes.io/master
       Operator:            Exists
       Effect:              NoExecute
       Key:                 node.kubernetes.io/not-ready
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoExecute
       Key:                 node.kubernetes.io/unreachable
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoSchedule
       Key:                 node.kubernetes.io/memory-pressure
       Operator:            Exists
   Roles:
     master 4
     worker 5
   Scan Tolerations: 6
     Operator:           Exists
   Schedule:             0 1 * * * 7
   Show Not Applicable:  false
   Strict Node Scan:     true
   Events:               <none>

   1

   The Compliance Operator creates a persistent volume (PV) that contains the results of the scans. By default, the PV will use access mode ReadWriteOnce because the Compliance Operator cannot make any assumptions about the storage classes configured on the cluster. Additionally, ReadWriteOnce access mode is available on most clusters. If you need to fetch the scan results, you can do so by using a helper pod, which also binds the volume. Volumes that use the ReadWriteOnce access mode can be mounted by only one pod at time, so it is important to remember to delete the helper pods. Otherwise, the Compliance Operator will not be able to reuse the volume for subsequent scans.

   2

   The Compliance Operator keeps results of three subsequent scans in the volume; older scans are rotated.

   3

   The Compliance Operator will allocate one GB of storage for the scan results.

   4 5

   If the scan setting uses any profiles that scan cluster nodes, scan these node roles.

   6

   The default scan setting object also scans all the nodes.

   7

   The default scan setting object runs scans at 01:00 each day.

   As an alternative to the default scan setting, you can use default-auto-apply, which has the following settings:

   Name:                      default-auto-apply
   Namespace:                 openshift-compliance
   Labels:                    <none>
   Annotations:               <none>
   API Version:               compliance.openshift.io/v1alpha1
   Auto Apply Remediations:   true
   Auto Update Remediations:  true
   Kind:                      ScanSetting
   Metadata:
     Creation Timestamp:  2022-10-18T20:21:00Z
     Generation:          1
     Managed Fields:
       API Version:  compliance.openshift.io/v1alpha1
       Fields Type:  FieldsV1
       fieldsV1:
         f:autoApplyRemediations: 1
         f:autoUpdateRemediations: 2
         f:rawResultStorage:
           .:
           f:nodeSelector:
             .:
             f:node-role.kubernetes.io/master:
           f:pvAccessModes:
           f:rotation:
           f:size:
           f:tolerations:
         f:roles:
         f:scanTolerations:
         f:schedule:
         f:showNotApplicable:
         f:strictNodeScan:
       Manager:         compliance-operator
       Operation:       Update
       Time:            2022-10-18T20:21:00Z
     Resource Version:  38840
     UID:               8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
   Raw Result Storage:
     Node Selector:
       node-role.kubernetes.io/master:
     Pv Access Modes:
       ReadWriteOnce
     Rotation:  3
     Size:      1Gi
     Tolerations:
       Effect:              NoSchedule
       Key:                 node-role.kubernetes.io/master
       Operator:            Exists
       Effect:              NoExecute
       Key:                 node.kubernetes.io/not-ready
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoExecute
       Key:                 node.kubernetes.io/unreachable
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoSchedule
       Key:                 node.kubernetes.io/memory-pressure
       Operator:            Exists
   Roles:
     master
     worker
   Scan Tolerations:
     Operator:           Exists
   Schedule:             0 1 * * *
   Show Not Applicable:  false
   Strict Node Scan:     true
   Events:               <none>

   1 2

   Setting autoUpdateRemediations and autoApplyRemediations flags to true allows you to easily create ScanSetting objects that auto-remediate without extra steps.

2. Create a ScanSettingBinding object that binds to the default ScanSetting object and scans the cluster using the cis and cis-node profiles. For example:

   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

3. Create the ScanSettingBinding object by running:

   $ oc create -f <file-name>.yaml -n openshift-compliance

   At this point in the process, the ScanSettingBinding object is reconciled and based on the Binding and the Bound settings. The Compliance Operator creates a ComplianceSuite object and the associated ComplianceScan objects.

4. Follow the compliance scan progress by running:

   $ oc get compliancescan -w -n openshift-compliance

   The scans progress through the scanning phases and eventually reach the DONE phase when complete. In most cases, the result of the scan is NON-COMPLIANT. You can review the scan results and start applying remediations to make the cluster compliant. See Managing Compliance Operator remediation for more information.

Procedure

1. Browse the available rules for the Red Hat Enterprise Linux CoreOS (RHCOS) ProfileBundle:

   $ oc get rules.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4

2. Browse the available variables in the same ProfileBundle:

   $ oc get variables.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4

3. Create a tailored profile named nist-moderate-modified:

   1. Choose which rules you want to add to the nist-moderate-modified tailored profile. This example extends the rhcos4-moderate profile by disabling two rules and changing one value. Use the rationale value to describe why these changes were made:

      Example new-profile-node.yaml

      apiVersion: compliance.openshift.io/v1alpha1
      kind: TailoredProfile
      metadata:
        name: nist-moderate-modified
      spec:
        extends: rhcos4-moderate
        description: NIST moderate profile
        title: My modified NIST moderate profile
        disableRules:
        - name: rhcos4-file-permissions-var-log-messages
          rationale: The file contains logs of error messages in the system
        - name: rhcos4-account-disable-post-pw-expiration
          rationale: No need to check this as it comes from the IdP
        setValues:
        - name: rhcos4-var-selinux-state
          rationale: Organizational requirements
          value: permissive

      Table 5.2. Attributes for spec variables

      Attribute	Description
      extends	Name of the Profile object upon which this TailoredProfile is built.
      title	Human-readable title of the TailoredProfile.
      disableRules	A list of name and rationale pairs. Each name refers to a name of a rule object that is to be disabled. The rationale value is human-readable text describing why the rule is disabled.
      manualRules	A list of name and rationale pairs. When a manual rule is added, the check result status will always be manual and remediation will not be generated. This attribute is automatic and by default has no values when set as a manual rule.
      enableRules	A list of name and rationale pairs. Each name refers to a name of a rule object that is to be enabled. The rationale value is human-readable text describing why the rule is enabled.
      description	Human-readable text describing the TailoredProfile.
      setValues	A list of name, rationale, and value groupings. Each name refers to a name of the value set. The rationale is human-readable text describing the set. The value is the actual setting.

   2. Add the tailoredProfile.spec.manualRules attribute:

      Example tailoredProfile.spec.manualRules.yaml

      apiVersion: compliance.openshift.io/v1alpha1
      kind: TailoredProfile
      metadata:
        name: ocp4-manual-scc-check
      spec:
        extends: ocp4-cis
        description: This profile extends ocp4-cis by forcing the SCC check to always return MANUAL
        title: OCP4 CIS profile with manual SCC check
        manualRules:
          - name: ocp4-scc-limit-container-allowed-capabilities
            rationale: We use third party software that installs its own SCC with extra privileges

   3. Create the TailoredProfile object:

      $ oc create -n openshift-compliance -f new-profile-node.yaml 1

      1

      The TailoredProfile object is created in the default openshift-compliance namespace.

      Example output

      tailoredprofile.compliance.openshift.io/nist-moderate-modified created

4. Define the ScanSettingBinding object to bind the new nist-moderate-modified tailored profile to the default ScanSetting object.

   Example new-scansettingbinding.yaml

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ScanSettingBinding
   metadata:
     name: nist-moderate-modified
   profiles:
     - apiGroup: compliance.openshift.io/v1alpha1
       kind: Profile
       name: ocp4-moderate
     - apiGroup: compliance.openshift.io/v1alpha1
       kind: TailoredProfile
       name: nist-moderate-modified
   settingsRef:
     apiGroup: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     name: default

5. Create the ScanSettingBinding object:

   $ oc create -n openshift-compliance -f new-scansettingbinding.yaml

   Example output

   scansettingbinding.compliance.openshift.io/nist-moderate-modified created

1. Explore the ComplianceSuite object:

   $ oc get compliancesuites nist-moderate-modified \
   -o json -n openshift-compliance | jq '.status.scanStatuses[].resultsStorage'

   Example output

   {
        "name": "ocp4-moderate",
        "namespace": "openshift-compliance"
   }
   {
        "name": "nist-moderate-modified-master",
        "namespace": "openshift-compliance"
   }
   {
        "name": "nist-moderate-modified-worker",
        "namespace": "openshift-compliance"
   }

   This shows the persistent volume claims where the raw results are accessible.

2. Verify the raw data location by using the name and namespace of one of the results:

   $ oc get pvc -n openshift-compliance rhcos4-moderate-worker

   Example output

   NAME                 	STATUS   VOLUME                                 	CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   rhcos4-moderate-worker   Bound	pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a   1Gi    	RWO        	gp2        	92m

3. Fetch the raw results by spawning a pod that mounts the volume and copying the results:

   $ oc create -n openshift-compliance -f pod.yaml

   Example pod.yaml

   apiVersion: "v1"
   kind: Pod
   metadata:
     name: pv-extract
   spec:
     containers:
       - name: pv-extract-pod
         image: registry.access.redhat.com/ubi8/ubi
         command: ["sleep", "3000"]
         volumeMounts:
         - mountPath: "/workers-scan-results"
           name: workers-scan-vol
     volumes:
       - name: workers-scan-vol
         persistentVolumeClaim:
           claimName: rhcos4-moderate-worker

4. After the pod is running, download the results:

   $ oc cp pv-extract:/workers-scan-results -n openshift-compliance .

   Important

   Spawning a pod that mounts the persistent volume will keep the claim as Bound. If the volume’s storage class in use has permissions set to ReadWriteOnce, the volume is only mountable by one pod at a time. You must delete the pod upon completion, or it will not be possible for the Operator to schedule a pod and continue storing results in this location.

5. After the extraction is complete, the pod can be deleted:

   $ oc delete pod pv-extract -n openshift-compliance

Procedure

1. List the nodes.

   $ oc get nodes -n openshift-compliance

   Example output

   NAME                                       STATUS  ROLES  AGE    VERSION
   ip-10-0-128-92.us-east-2.compute.internal  Ready   master 5h21m  v1.23.3+d99c04f
   ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
   ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
   ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.23.3+d99c04f
   ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.23.3+d99c04f

2. Add a label to nodes.

   $ oc -n openshift-compliance \
   label node ip-10-0-166-81.us-east-2.compute.internal \
   node-role.kubernetes.io/<machine_config_pool_name>=

   Example output

   node/ip-10-0-166-81.us-east-2.compute.internal labeled

3. Create custom MachineConfigPool CR.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: <machine_config_pool_name>
     labels:
       pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: '' 1
   spec:
     machineConfigSelector:
     matchExpressions:
     - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]}
     nodeSelector:
     matchLabels:
       node-role.kubernetes.io/<machine_config_pool_name>: ""

   1

   The labels field defines label name to add for Machine config pool(MCP).

4. Verify MCP created successfully.

   $ oc get mcp -w

Procedure

1. To check the configuration against all pools in an example cluster containing master, worker, and custom example node pools, set the value of the ocp-var-role-master and opc-var-role-worker fields to example in the TailoredProfile object:

   apiVersion: compliance.openshift.io/v1alpha1
   kind: TailoredProfile
   metadata:
     name: cis-example-tp
   spec:
     extends: ocp4-cis
     title: My modified NIST profile to scan example nodes
     setValues:
     - name: ocp4-var-role-master
       value: example
       rationale: test for example nodes
     - name: ocp4-var-role-worker
       value: example
       rationale: test for example nodes
     description: cis-example-scan

2. Add the example role to the ScanSetting object that will be stored in the ScanSettingBinding CR:

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ScanSetting
   metadata:
     name: default
     namespace: openshift-compliance
   rawResultStorage:
     rotation: 3
     size: 1Gi
   roles:
   - worker
   - master
   - example
   scanTolerations:
   - effect: NoSchedule
     key: node-role.kubernetes.io/master
     operator: Exists
   schedule: '0 1 * * *'

3. Create a scan that uses the ScanSettingBinding CR:

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ScanSettingBinding
   metadata:
     name: cis
     namespace: openshift-compliance
   profiles:
   - apiGroup: compliance.openshift.io/v1alpha1
     kind: Profile
     name: ocp4-cis
   - apiGroup: compliance.openshift.io/v1alpha1
     kind: Profile
     name: ocp4-cis-node
   - apiGroup: compliance.openshift.io/v1alpha1
     kind: TailoredProfile
     name: cis-example-tp
   settingsRef:
     apiGroup: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     name: default

Procedure

1. The example below uses the ocp4-ocp-allowed-registries-for-import rule, which would fail on a default OpenShift Container Platform installation. Inspect the rule oc get rule.compliance/ocp4-ocp-allowed-registries-for-import -oyaml, the rule is to limit the registries the users are allowed to import images from by setting the allowedRegistriesForImport attribute, The warning attribute of the rule also shows the API object checked, so it can be modified and remediate the issue:

   $ oc edit image.config.openshift.io/cluster

   Example output

   apiVersion: config.openshift.io/v1
   kind: Image
   metadata:
     annotations:
       release.openshift.io/create-only: "true"
     creationTimestamp: "2020-09-10T10:12:54Z"
     generation: 2
     name: cluster
     resourceVersion: "363096"
     selfLink: /apis/config.openshift.io/v1/images/cluster
     uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e
   spec:
     allowedRegistriesForImport:
     - domainName: registry.redhat.io
   status:
     externalRegistryHostnames:
     - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com
     internalRegistryHostname: image-registry.openshift-image-registry.svc:5000

2. Re-run the scan:

   $ oc -n openshift-compliance \
   annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

Procedure

1. Search for any outdated remediations:

   $ oc -n openshift-compliance get complianceremediations \
   -l complianceoperator.openshift.io/outdated-remediation=

   Example output

   NAME                              STATE
   workers-scan-no-empty-passwords   Outdated

   The currently applied remediation is stored in the Outdated attribute and the new, unapplied remediation is stored in the Current attribute. If you are satisfied with the new version, remove the Outdated field. If you want to keep the updated content, remove the Current and Outdated attributes.

2. Apply the newer version of the remediation:

   $ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty-passwords \
   --type json -p '[{"op":"remove", "path":/spec/outdated}]'

3. The remediation state will switch from Outdated to Applied:

   $ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords

   Example output

   NAME                              STATE
   workers-scan-no-empty-passwords   Applied

4. The nodes will apply the newer remediation version and reboot.

Procedure

1. Set the apply flag to false:

   $ oc -n openshift-compliance \
   patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \
   --patch '{"spec":{"apply":false}}' --type=merge

2. The remediation status will change to NotApplied and the composite MachineConfig object would be re-rendered to not include the remediation.

   Important

   All affected nodes with the remediation will be rebooted.

Procedure

1. Locate the scan-name and compliance check for the one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available remediation:

   $ oc -n openshift-compliance get remediation \ one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml

   Example output

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ComplianceRemediation
   metadata:
     annotations:
       compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available
     creationTimestamp: "2022-01-05T19:52:27Z"
     generation: 1
     labels:
       compliance.openshift.io/scan-name: one-rule-tp-node-master 1
       compliance.openshift.io/suite: one-rule-ssb-node
     name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
     namespace: openshift-compliance
     ownerReferences:
     - apiVersion: compliance.openshift.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ComplianceCheckResult
       name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
       uid: fe8e1577-9060-4c59-95b2-3e2c51709adc
     resourceVersion: "84820"
     uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355
   spec:
     apply: true
     current:
       object:
         apiVersion: machineconfiguration.openshift.io/v1
         kind: KubeletConfig
         spec:
           kubeletConfig:
             evictionHard:
               imagefs.available: 10% 2
     outdated: {}
     type: Configuration
   status:
     applicationState: Applied

   1

   The scan name of the remediation.

   2

   The remediation that was added to the KubeletConfig objects.

   Note

   If the remediation invokes an evictionHard kubelet configuration, you must specify all of the evictionHard parameters: memory.available, nodefs.available, nodefs.inodesFree, imagefs.available, and imagefs.inodesFree. If you do not specify all parameters, only the specified parameters are applied and the remediation will not function properly.

2. Remove the remediation:

   1. Set apply to false for the remediation object:

      $ oc -n openshift-compliance patch \
      complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available \
      -p '{"spec":{"apply":false}}' --type=merge

   2. Using the scan-name, find the KubeletConfig object that the remediation was applied to:

      $ oc -n openshift-compliance get kubeletconfig \
      --selector compliance.openshift.io/scan-name=one-rule-tp-node-master

      Example output

      NAME                                 AGE
      compliance-operator-kubelet-master   2m34s

   3. Manually remove the remediation, imagefs.available: 10%, from the KubeletConfig object:

      $ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master

      Important

      All affected nodes with the remediation will be rebooted.

Procedure

1. Create the ConfigMap object from a file:

   $ oc -n openshift-compliance \
   create configmap nist-moderate-modified \
   --from-file=tailoring.xml=/path/to/the/tailoringFile.xml

2. Reference the tailoring file in a scan that belongs to a suite:

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ComplianceSuite
   metadata:
     name: workers-compliancesuite
   spec:
     debug: true
     scans:
       - name: workers-scan
         profile: xccdf_org.ssgproject.content_profile_moderate
         content: ssg-rhcos4-ds.xml
         contentImage: quay.io/complianceascode/ocp4:latest
         debug: true
     tailoringConfigMap:
         name: nist-moderate-modified
     nodeSelector:
       node-role.kubernetes.io/worker: ""

Procedure

1. Define the SCC in a YAML file named restricted-adjusted-compliance.yaml:

   SecurityContextConstraints object definition

     allowHostDirVolumePlugin: false
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: true
     allowPrivilegedContainer: false
     allowedCapabilities: null
     apiVersion: security.openshift.io/v1
     defaultAddCapabilities: null
     fsGroup:
       type: MustRunAs
     kind: SecurityContextConstraints
     metadata:
       name: restricted-adjusted-compliance
     priority: 30 1
     readOnlyRootFilesystem: false
     requiredDropCapabilities:
     - KILL
     - SETUID
     - SETGID
     - MKNOD
     runAsUser:
       type: MustRunAsRange
     seLinuxContext:
       type: MustRunAs
     supplementalGroups:
       type: RunAsAny
     users:
     - system:serviceaccount:openshift-compliance:api-resource-collector 2
     volumes:
     - configMap
     - downwardAPI
     - emptyDir
     - persistentVolumeClaim
     - projected
     - secret

   1

   The priority of this SCC must be higher than any other SCC that applies to the system:authenticated group.

   2

   Service Account used by Compliance Operator Scanner pod.

2. Create the SCC:

   $ oc create -n openshift-compliance  -f restricted-adjusted-compliance.yaml

   Example output

   securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created

Verification

1. Verify the SCC was created:

   $ oc get -n openshift-compliance scc restricted-adjusted-compliance

   Example output

   NAME                             PRIV    CAPS         SELINUX     RUNASUSER        FSGROUP     SUPGROUP   PRIORITY   READONLYROOTFS   VOLUMES
   restricted-adjusted-compliance   false   <no value>   MustRunAs   MustRunAsRange   MustRunAs   RunAsAny   30         false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

Procedure

1. To increase the Operator’s memory limits to 500 Mi, create the following patch file named co-memlimit-patch.yaml:

   spec:
     config:
       resources:
         limits:
           memory: 500Mi

2. Apply the patch file:

   $ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge

1. Navigate to the Operators Installed Operators page.
2. Delete all ScanSettingBinding, ComplainceSuite, ComplianceScan, and ProfileBundle objects.
3. Switch to the Administration Operators Installed Operators page.
4. Click the Options menu on the Compliance Operator entry and select Uninstall Operator.
5. Switch to the Home Projects page.
6. Search for 'compliance'.

7. Click the Options menu next to the openshift-compliance project, and select Delete Project.

   1. Confirm the deletion by typing openshift-compliance in the dialog box, and click Delete.

Procedure

1. Extract the oc-compliance image to get the oc-compliance binary:

   $ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/

   Example output

   W0611 20:35:46.486903   11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.

   You can now run oc-compliance.

Procedure

1. Run:

   $ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]

   • If you omit the -S flag, the default scan setting provided by the Compliance Operator is used.
   • The object type is the Kubernetes object type, which can be profile or tailoredprofile. More than one object can be provided.
   • The object name is the name of the Kubernetes resource, such as .metadata.name.

   • Add the --dry-run option to display the YAML file of the objects that are created.

     For example, given the following profiles and scan settings:

     $ oc get profile.compliance -n openshift-compliance

     Example output

     NAME              AGE
     ocp4-cis          9m54s
     ocp4-cis-node     9m54s
     ocp4-e8           9m54s
     ocp4-moderate     9m54s
     ocp4-ncp          9m54s
     rhcos4-e8         9m54s
     rhcos4-moderate   9m54s
     rhcos4-ncp        9m54s
     rhcos4-ospp       9m54s
     rhcos4-stig       9m54s

     $ oc get scansettings -n openshift-compliance

     Example output

     NAME                 AGE
     default              10m
     default-auto-apply   10m

2. To apply the default settings to the ocp4-cis and ocp4-cis-node profiles, run:

   $ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node

   Example output

   Creating ScanSettingBinding my-binding

   Once the ScanSettingBinding CR is created, the bound profile begins scanning for both profiles with the related settings. Overall, this is the fastest way to begin scanning with the Compliance Operator.

Procedure

1. View the remediations for a profile:

   $ oc compliance fetch-fixes profile ocp4-cis -o /tmp

   Example output

   No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 1
   No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled'
   No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup'
   Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml
   No fixes to persist for rule 'ocp4-api-server-audit-log-path'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-node'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac'
   No fixes to persist for rule 'ocp4-api-server-basic-auth'
   No fixes to persist for rule 'ocp4-api-server-bind-address'
   No fixes to persist for rule 'ocp4-api-server-client-ca'
   Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml
   Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml

   1

   The No fixes to persist warning is expected whenever there are rules in a profile that do not have a corresponding remediation, because either the rule cannot be remediated automatically or a remediation was not provided.

2. You can view a sample of the YAML file. The head command will show you the first 10 lines:

   $ head /tmp/ocp4-api-server-audit-log-maxsize.yaml

   Example output

   apiVersion: config.openshift.io/v1
   kind: APIServer
   metadata:
     name: cluster
   spec:
     maximumFileSizeMegabytes: 100

3. View the remediation from a ComplianceRemediation object created after a scan:

   $ oc get complianceremediations -n openshift-compliance

   Example output

   NAME                                             STATE
   ocp4-cis-api-server-encryption-provider-cipher   NotApplied
   ocp4-cis-api-server-encryption-provider-config   NotApplied

   $ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp

   Example output

   Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

4. You can view a sample of the YAML file. The head command will show you the first 10 lines:

   $ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

   Example output

   apiVersion: config.openshift.io/v1
   kind: APIServer
   metadata:
     name: cluster
   spec:
     encryption:
       type: aescbc

1. Define your compliance scan requirements
2. Configure the compliance scan settings
3. Process compliance requirements with compliance scans settings
4. Monitor the compliance scans
5. Check the compliance scan results