Add enhancement document for CEL scanner by Vincent056 · Pull Request #649 · ComplianceAsCode/compliance-operator

Vincent056 · 2025-01-17T15:48:28Z

Adding the CEL enhancement document.

openshift-ci · 2025-01-17T15:48:35Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Vincent056

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [Vincent056]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

github-actions · 2025-01-17T16:02:32Z

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:649-15b19ff5dbadb3c9192af61c5268618233739e41

BillDett · 2025-01-23T20:33:27Z

Wondering about calling these CustomRules. For the initial roll out of this we'll be supporting TailoredProfiles so it makes sense that the rules would be 'custom'. But at some point we expect to drop SCAP and migrate our content to this new strategy, so CEL will be the default. Will we still want to call these CustomRules? Does a name like KubeRule have more longevity?

github-actions · 2025-01-24T15:56:48Z

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:649-7d1e395282bd62eae65e583e4d48bdae4a34f53f

Vincent056 · 2025-01-24T16:00:04Z

Wondering about calling these CustomRules. For the initial roll out of this we'll be supporting TailoredProfiles so it makes sense that the rules would be 'custom'. But at some point we expect to drop SCAP and migrate our content to this new strategy, so CEL will be the default. Will we still want to call these CustomRules? Does a name like KubeRule have more longevity?

that's a good point! we’re starting with CustomRules since these are the ones users can modify, unlike the regular Rule CRs that are created and managed by the operator (the ones we ship). Any changes to Rule object will get overridden. It’s similar to how TailoredProfiles work compared to the default Profiles we provide.

That said, once CEL becomes the default and we’re fully away from SCAP, we will add new field ScanType to the Rule CR and mirror CustomRules. I am thinking whether we highlight it’s user-defined or shipped, I am not good at naming but would UserRule or maybe CustomKubeRule sounds better

github-actions · 2025-01-24T16:12:10Z

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:649-3d8bd58c743c1b13db7839375544a7f5bb019d63

github-actions · 2025-01-24T16:23:32Z

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:649-e96f9aec5e6fbdb4de98a6df6a4889e95150c9d3

rhmdnd · 2025-01-31T20:16:02Z

enhancements/cel-scanner.md

+
+## Summary
+
+This enhancement proposes introducing a **new CRD** called `CustomRule` to provide **CEL** (Common Expression Language) scanning capabilities in the Compliance Operator. By creating a stand-alone CRD, instead of modifying the existing `ComplianceScan` resource, we preserve backward compatibility for the OpenSCAP-based workflows.


This also means we have the ability to experiment with the CEL scanning implementation in CustomRule before we bake it into the Rule.

rhmdnd

Thanks for all the detail. It definitely helped me understand more of the approach!

rhmdnd · 2025-01-31T20:19:33Z

enhancements/cel-scanner.md

+
+### Background
+
+The Compliance Operator currently relies on `oscap`. Developing compliance checks is a complex process requiring:


Nit: We could supplement the following with a short summary for readers who aren't intimately familiar with the internals of the Compliance Operator, oscap, or SCAP.

relies on oscap

The oscap binary is used to perform vulnerability scanning and compliance checks on systems. It is a command-line tool that uses the OpenSCAP framework to scan systems for vulnerabilities, non-compliance, and policy violations.

rhmdnd · 2025-01-31T20:21:06Z

enhancements/cel-scanner.md

+
+### Why CEL?
+
+- CEL is already popular and widely used throughout the Kubernetes community, thus **reducing the learning curve**.


Yes - specifically reducing the learning curve for cluster administrators and/or security teams looking to write their own compliance content.

We could also supplement this with a link to CEL K8s docs - for folks to learn more:

https://kubernetes.io/docs/reference/using-api/cel/

rhmdnd · 2025-01-31T20:22:13Z

enhancements/cel-scanner.md

+
+- CEL is already popular and widely used throughout the Kubernetes community, thus **reducing the learning curve**.
+- It integrates with typical cluster-admin workflows; writing or editing a CEL rule is more straightforward than SCAP/OVAL content.
+- We already have a proof-of-concept (POC) that integrates CEL scanning with the Compliance Operator. 


Link to the PoC here would be good if people are curious how we approach that work.

rhmdnd · 2025-01-31T20:24:26Z

enhancements/cel-scanner.md

+
+1. **Backward Compatibility**  
+   - Users relying on existing SCAP-based scans (`ComplianceScan`) see no difference.  
+   - We do **not** add new fields to `ComplianceScan`; instead, we introduce a new CRD for CEL-based scanning.


This means users opt-into the new functionality by creating a TailoredProfile, which contains CustomRule objects, and then linking the TailoredProfile to a ScanSetting with a ScanSettingBinding, re-using much of the flow users are familiar with today 👍🏻

rhmdnd · 2025-01-31T20:25:10Z

enhancements/cel-scanner.md

+
+2. **Simplified Architecture**  
+   - A single container (the “cel-scanner”) handles *resource fetching*, *rule evaluation*, and *result creation*.  
+   - **No** need to coordinate multiple pods or containers for scanning/log-collection tasks.


Yessss 👏🏻

Specifically the code we have to shuffle results around with config maps between components.

rhmdnd · 2025-01-31T21:53:13Z

enhancements/cel-scanner.md

+  The aggregator sees the `ConfigMap` (by label) and creates corresponding `ComplianceCheckResult` objects.  
+- Option 2 (Direct creation of `ComplianceCheckResult` CRs from the scanner): The scanner can create them in-cluster immediately.  
+
+Depending on the desired flow, we can either **continue the aggregator approach** or have the “cel-scanner” do it directly.  


What do you feel is the better approach here?

I think we can go with option2 agree with what you have above

rhmdnd · 2025-01-31T21:55:17Z

enhancements/cel-scanner.md

+
+### 6. TailoredProfile Controller
+
+- Ensures that if a `TailoredProfile` references a `CustomRule` (with `scannerType: cel`), the resulting annotation `scanner-type: cel` is set.  


How are we going to put guard rails around using CustomRule with SCAP content? That should break, right?

Yes, we will check for those

rhmdnd · 2025-01-31T21:56:31Z

enhancements/cel-scanner.md

+  - A new CRD Extends existing `ComplianceRule` logic with CEL-specific fields.  
+
+- **`TailoredProfile` CRD**:  
+  - Add Type filed in Spec.enableRules 


nit: field?

rhmdnd · 2025-01-31T21:59:22Z

enhancements/cel-scanner.md

+
+### Implementation Details / Notes / Constraints
+
+- **RBAC**: The “cel-scanner” Pod needs read permissions (`get/list/watch`) for every resource type mentioned in the `inputs`.


The API resource collector is going to use the existing service account, right?

If so - is the expectations that cluster admins update that role to include the permissions for the custom rules they've written?

https://github.com/ComplianceAsCode/compliance-operator/blob/master/config/rbac/api_resource_collector_cluster_role.yaml

Will the compliance operator overwrite those permissions on update?

Or does this mean users can only write CustomRule resources for permissions that are already supported by the API resource collector?

we can let user to choose what service account to use, if they don't we will use a default one.

rhmdnd · 2025-01-31T22:03:13Z

enhancements/cel-scanner.md

+
+Putting it all together:
+
+1. **User** defines a `CustomRule` with `scannerType:"cel"`.


Similar to the above question.

If I write a CustomRule to evaluate a resource that isn't include in the API resources aggregator permissions, do I need a subsequent step here to make sure it can fetch those resources?

Otherwise, if I understand correctly, it's entirely possible that a user would get all the way through the flow, up to the scan, only to have it fail on a 403?

I think that's a good point, yeah, we can make it that we check for the permission before a scan is happened.

BillDett · 2025-02-05T16:29:58Z

Can we add a section discussion the relationship/difference between a CustomRule and a ValidatingAdmissionPolicy? Specifically, how each is expected to be used, and how we might let a CustomRule possibly 'lift' a CEL expression from a ValidatingAdmissionPolicy? This could be useful as customers might have their own collection of VAPs that they want to re-use.f

Vincent056 · 2025-02-08T00:20:56Z

Can we add a section discussion the relationship/difference between a CustomRule and a ValidatingAdmissionPolicy? Specifically, how each is expected to be used, and how we might let a CustomRule possibly 'lift' a CEL expression from a ValidatingAdmissionPolicy? This could be useful as customers might have their own collection of VAPs that they want to re-use.f

I think makes sense, I was reviewing some of existing VAPs, I think we will have the ability to wield what VAPs has to Compliance Operator and reuse those existing VAPs to CO. Since VAP is always being evaluated, the time when we fetch the VAP is the current state of things

openshift-ci bot requested review from rhmdnd and xiaojiey January 17, 2025 15:48

openshift-ci bot added the approved label Jan 17, 2025

Vincent056 force-pushed the cel-en branch from 15b19ff to 7d1e395 Compare January 24, 2025 15:49

Vincent056 force-pushed the cel-en branch from 7d1e395 to 3d8bd58 Compare January 24, 2025 16:04

Add CEL enhancement doc

e96f9ae

Vincent056 force-pushed the cel-en branch from 3d8bd58 to e96f9ae Compare January 24, 2025 16:16

rhmdnd reviewed Jan 31, 2025

View reviewed changes

Vincent056 mentioned this pull request Feb 3, 2025

CMP-2870, CMP-2869, CMP-2870, CMP-2872, CMP-2868: Compliance SDK Compliance Operator Implementation #671

Merged

rhmdnd added the CEL CEL features and functionality label Feb 27, 2025


		## Summary

		This enhancement proposes introducing a new CRD called `CustomRule` to provide CEL (Common Expression Language) scanning capabilities in the Compliance Operator. By creating a stand-alone CRD, instead of modifying the existing `ComplianceScan` resource, we preserve backward compatibility for the OpenSCAP-based workflows.


		### Background

		The Compliance Operator currently relies on `oscap`. Developing compliance checks is a complex process requiring:


		### Why CEL?

		- CEL is already popular and widely used throughout the Kubernetes community, thus reducing the learning curve.


		### 6. TailoredProfile Controller

		- Ensures that if a `TailoredProfile` references a `CustomRule` (with `scannerType: cel`), the resulting annotation `scanner-type: cel` is set.


		### Implementation Details / Notes / Constraints

		- RBAC: The “cel-scanner” Pod needs read permissions (`get/list/watch`) for every resource type mentioned in the `inputs`.


		Putting it all together:

		1. User defines a `CustomRule` with `scannerType:"cel"`.

Conversation

Vincent056 commented Jan 17, 2025

Uh oh!

openshift-ci bot commented Jan 17, 2025

Uh oh!

github-actions bot commented Jan 17, 2025

Uh oh!

BillDett commented Jan 23, 2025

Uh oh!

github-actions bot commented Jan 24, 2025

Uh oh!

Vincent056 commented Jan 24, 2025

Uh oh!

github-actions bot commented Jan 24, 2025

Uh oh!

github-actions bot commented Jan 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rhmdnd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vincent056 Feb 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BillDett commented Feb 5, 2025

Uh oh!

Vincent056 commented Feb 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Vincent056 Feb 8, 2025 •

edited

Loading