Epic Goal

The Compliance Operator supports CustomRules where users can define their own checks and run them against the platform (OpenShift/Kubernetes resources). But, we also need to think about supporting this for node checks, where users can specify rules that run an each node in a particular node pool, and the operator will aggregate the results together like it does today with SCAP.

Why is this important?

This gives users the flexibility to write more checks against their infrastructure, without having all the compliance content come from Red Hat's ISC team.

Scenarios

1. As a security officer responsible for the compliance posture of an OpenShift cluster, I want to specify rules that must run on all or some nodes in an OpenShift cluster and have the Compliance Operator present those results like it does with OpenSCAP today so that I can assess the infrastructure compliance of my cluster

Acceptance Criteria

• Users can create CustomRules that check file permissions on nodes
• Users can create CustomRules that check file contents on nodes
• Users can create CustomRules that check directory permissions and contents

Dependencies (internal and external)

1. This work will have a dependency on the compliance-sdk, which needs to expose specific node-related checks (checking processes, files, etc.).

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>