Problem Statement

The CIS benchmark requires a lot of checks for settings in the Kubelet’s configuration. OpenShift currently has a dedicated object to do such overrides. It takes the form of a Custom Resource called KubeletConfig, presently managed and backed by the MachineConfig Operator. Creating remediations in a general way is non-trivial for this operator because of the following challenges:

• KubeletConfig objects may have any name (we can’t predict it)
• The KubeletConfig is a singleton object, and the first one created will be taken into account.
• We’d need a KubeletConfig object for each MachineConfigPool (similar to MachineConfigs, which we are indeed able to remediate already).
• Any change to KubeletConfig objects will trigger a restart of the set of nodes that comprise the pool.

Hence, remediating these types of objects would require special handling (similar to what we do for MachineConfigs right now), but with extra considerations. Remediations for KubeletConfig objects should:

• Remediate a KubeletConfig object for each role we track in our scans.
• See if a KubeletConfig object already exists for a pool, and use that if that’s the case.
• Aggregate different remediations into one single KubeletConfig object per tracked pool.

Epic Goal

• The Compliance Operator should be able to remediate KubeletConfig objects

Why is this important?

• We currently don’t remediate everything with the Compliance Operator. Doing so would give us more coverage for automatic remediations, thus making the operator more useful.

Scenarios

1. As an administrator, I'd like to get my clusters to comply with the CIS benchmark. A lot of the items in this benchmark require changes to a KubeletConfig object. The operator should be able to help me in this.

Quality Assurance Needs

Some CIS Benchmark remediations are added to use by the Compliance Operator(See CMP-1114 and CMP-1113). Noted: Some CIS rules remediation that uses XCCDF variables are dependent on CMP-911. The CIS Profile needs to be tested and ensure the following:

• The rules are able to get the necessary information
• The rules generate appropriate remediations
• The remediations indeed address the found gaps (defines by the rules)
• The cluster is in a working state after the remediations have been applied

A proposed test is as follows:

• In a clean cluster, install the compliance-operator
• Run a scan for the CIS profile. This will be both a Platform scan and a Node scan which are the ocp4 and rhcos4 profiles respectively.
• Apply all the suggested remediations
• Apply manual fixes for findings that can't be automatically remediated as suggested by the results (e.g. configure a relevant IdP, use signed images only, etc.)
• Re-scan
• Verify that the rules which had issues were fixed and are now in a compliant state
• Run a smoke test to verify that the cluster is still usable

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>