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

      Expand

      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.

      Show more

   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"]