CMP-4040, CMP-4041: Add support for CEL based rules and profiles

.claude/CLAUDE.md

@@ -158,6 +158,122 @@ template:
         pkgname@ubuntu2204: avahi-daemon    # Platform-specific overrides
 ```
 
+## CEL Checking Engine (Kubernetes/OpenShift)
+
+CEL (Common Expression Language) provides native Kubernetes resource evaluation without requiring shell access or OVAL checks. Rules using the CEL checking engine are used by the compliance-operator for Kubernetes and OpenShift compliance scanning.
+
+**Important:** Rules with CEL checks are **excluded** from SCAP data streams and are generated as a separate `${PRODUCT}-cel-content.yaml` file.
+
+### Rule Structure for CEL Checks
+
+Rules using CEL checks use a **split-file structure** to separate metadata from CEL-specific content:
+
+- **`rule.yml`** - Contains metadata (title, description, rationale, severity, references, etc.)
+- **`cel/shared.yml`** - Contains CEL-specific fields (check_type, inputs, expression)
+
+This allows rules to support **both CEL and OVAL** checks during migration from OVAL to CEL.
+
+**Example rule.yml:**
+```yaml
+documentation_complete: true
+
+title: 'Rule Title'
+
+description: |-
+    Description of what the rule checks.
+
+rationale: |-
+    Why this rule matters.
+
+severity: medium
+
+ocil: |-                   # Optional: Manual check instructions
+    Run the following command:
+    <pre>$ oc get pods</pre>
+
+references:                # Optional: Same as regular rules
+    cis@ocp4: 1.2.3
+    nist: CM-6
+```
+
+**Example cel/shared.yml:**
+```yaml
+check_type: Platform        # Usually Platform for K8s checks
+
+failure_reason: |-          # Optional: Custom failure message
+    The resource is not properly configured.
+
+expression: |-             # REQUIRED: CEL expression (must evaluate to boolean)
+    resource.spec.enabled == true
+
+inputs:                    # REQUIRED: Kubernetes resources to evaluate
+  - name: resource
+    kubernetes_input_spec:
+      api_version: v1
+      resource: pods
+      resource_name: my-pod          # Optional: specific resource
+      resource_namespace: default    # Optional: specific namespace
+```
+
+**Note:** The build system automatically detects rules with CEL checks by the presence of the `cel/` directory.
+
+### CEL Expression Examples
+
+Simple boolean check:
+```yaml
+expression: resource.spec.enabled == true
+```
+
+Check for field absence:
+```yaml
+expression: !has(resource.spec.insecureField)
+```
+
+Multiple conditions:
+```yaml
+expression: |-
+    resource.spec.replicas >= 3 &&
+    has(resource.spec.securityContext) &&
+    resource.spec.securityContext.runAsNonRoot == true
+```
+
+### CEL Profile Format
+
+Profiles that select rules using CEL checks must have `scanner_type: CEL`:
+
+```yaml
+documentation_complete: true
+
+title: 'CIS VM Extension Benchmark'
+
+description: |-
+    Profile description.
+
+scanner_type: CEL    # REQUIRED: Marks this as a CEL profile (excluded from XCCDF)
+
+selections:
+    - kubevirt-nonroot-feature-gate-is-enabled
+    - kubevirt-no-permitted-host-devices
+```
+
+**Note:** 
+- Profiles use `scanner_type: CEL` to indicate they target the CEL checking engine and should be excluded from XCCDF/datastream builds.
+- A rule can have both `cel/` (for CEL checks) and `template:` (for OVAL checks) to support both checking engines during migration.
+
+**Important:** Use hyphens rule IDs (Kubernetes naming convention), not underscores.
+
+### Enabling CEL Content for a Product
+
+In `products/${PRODUCT}/CMakeLists.txt`:
+
+```cmake
+set(PRODUCT "ocp4")
+set(PRODUCT_CEL_ENABLED TRUE)  # Enable CEL content generation
+ssg_build_product(${PRODUCT})
+```
+
+See `docs/manual/developer/13_cel_content.md` for complete CEL documentation.
+
 ## Common Jinja2 Macros
 
 Used in rule descriptions, OCIL, fixtext, and warnings fields:
@@ -279,19 +395,35 @@ Common selection patterns:
 ## Build Instructions
 
 ```bash
-# Build a single product (full build)
+# Build a single product (full build, includes CEL content if PRODUCT_CEL_ENABLED)
 ./build_product ocp4
 
-# Build data stream only (faster, skips guides and tables)
+# Build data stream only (faster, skips guides, tables, and CEL content)
+./build_product ocp4 --datastream
+# Short form (only builds datastream):
+./build_product ocp4 -d
+# Legacy form (still supported):
 ./build_product ocp4 --datastream-only
 
+# Build data stream and CEL content
+./build_product ocp4 --datastream --cel-content=ocp4
+
+# Build only CEL content (no data stream)
+./build_product --cel-content=ocp4
+
+# Build CEL content for multiple products
+./build_product --cel-content=ocp4,rhel9
+
 # Build with only specific rules (fastest, for testing individual rules)
-./build_product ocp4 --datastream-only --rule-id api_server_tls_security_profile
+./build_product ocp4 --datastream --rule-id api_server_tls_security_profile
 ```
 
 Build output goes to `build/`. The data stream file is at:
 `build/ssg-<product>-ds.xml`
 
+For products with CEL content enabled, the CEL content file is at:
+`build/<product>-cel-content.yaml`
+
 ## Guidelines for Claude
 
 1. **Always show proposals before making changes.** Present the full content of any new or modified file and wait for explicit approval.

.github/workflows/ocp-test-profiles.yaml

@@ -1,7 +1,7 @@
 name: Trigger OCP Tests When Relevant
 on:
   pull_request:
     branches: [ master, 'stabilization*' ]
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.number || github.run_id }}
   cancel-in-progress: true
@@ -15,7 +15,7 @@
       pull-requests: write
     steps:
       - name: Install Deps
         run: dnf install -y cmake make openscap-utils python3-pyyaml python3-jinja2 git python3-deepdiff python3-requests jq python3-pip nodejs
       - name: Install deps python
         run: pip install gitpython xmldiff
       - name: Checkout
@@ -33,10 +33,10 @@
       - name: Find forking point
         env:
           BASE_BRANCH: ${{ github.base_ref }}
         run: echo "FORK_POINT=$(git merge-base origin/$BASE_BRANCH ${{ github.event.pull_request.head.sha }})" >> $GITHUB_OUTPUT
         id: fork_point
       - name: Detect content changes in the PR
         run: python3 ./ctf/content_test_filtering.py pr --base ${{ steps.fork_point.outputs.FORK_POINT }} --remote_repo ${{ github.server_url }}/${{ github.repository }}  --verbose --rule --output json ${{ github.event.pull_request.number }} > ctf-output.json
       - name: Test if there are no content changes
         run: echo "CTF_OUTPUT_SIZE=$(stat --printf="%s" ctf-output.json)" >> $GITHUB_OUTPUT
         id: ctf
@@ -51,23 +51,23 @@
       - name: Get product attribute
         if: ${{ steps.ctf.outputs.CTF_OUTPUT_SIZE != '0' }}
         id: product
         uses: notiz-dev/github-action-json-property@a5a9c668b16513c737c3e1f8956772c99c73f6e8 # v0.2.0
         with:
           path: 'ctf-output.json'
           prop_path: 'product'
 
       - name: Build product OCP and RHCOS content
         if: ${{ steps.ctf.outputs.CTF_OUTPUT_SIZE != '0' && (contains(steps.product.outputs.prop, 'ocp4') || contains(steps.product.outputs.prop, 'rhcos4')) }}
-        run: ./build_product -d ocp4 rhcos4
+        run: ./build_product --datastream ocp4 rhcos4 --cel-content=ocp4
 
       - name: Process list of rules into a list of product-profiles to test
         if: ${{ steps.ctf.outputs.CTF_OUTPUT_SIZE != '0' && (contains(steps.product.outputs.prop, 'ocp4') || contains(steps.product.outputs.prop, 'rhcos4')) }}
         id: profiles_to_test 
         run: |
           # Let's grab the profiles for which we have a CI job configured
           PROW_CONFIG=https://raw.githubusercontent.com/openshift/release/refs/heads/master/ci-operator/config/ComplianceAsCode/content/ComplianceAsCode-content-master.yaml
           curl -o prow_config.yaml ${PROW_CONFIG}
           readarray -t TESTED_PROFILES <<< $(grep -r PROFILE= ./prow_config.yaml | sort -u | sed 's/.*export PROFILE=\(.*\)/\1/')
 
           RULES=$(cat ctf-output.json | jq -r '.rules[]')
 

Dockerfiles/compliance-operator-content-konflux.Containerfile

@@ -84,8 +84,8 @@ RUN grep -lr 'documentation_complete: false' ./products | xargs -I '{}' \
 # Build the OpenShift and RHCOS content for x86, aarch64 and ppc64le architectures.
 # Only build OpenShift content for s390x architectures.
 RUN if [ "$(uname -m)" = "x86_64" ] || [ "$(uname -m)" = "aarch64" ] || [ "$(uname -m)" = "ppc64le" ]; then \
-        ./build_product ocp4 rhcos4 --datastream-only; \
-        else ./build_product ocp4 --datastream-only; \
+        ./build_product ocp4 rhcos4 --datastream --cel-content=ocp4; \
+        else ./build_product ocp4 --datastream --cel-content=ocp4; \
         fi
 
 FROM registry.redhat.io/ubi9/ubi-minimal:latest
@@ -110,3 +110,4 @@ LABEL \
 WORKDIR /
 COPY --from=builder /go/src/github.com/ComplianceAsCode/content/LICENSE /licenses/LICENSE
 COPY --from=builder /go/src/github.com/ComplianceAsCode/content/build/ssg-*-ds.xml .
+COPY --from=builder /go/src/github.com/ComplianceAsCode/content/build/*-cel-content.yaml .

Dockerfiles/ocp4_content

@@ -20,6 +20,7 @@ RUN if [ "$(uname -m)" == "x86_64" ] || [ "$(uname -m)" == "aarch64" ]; then \
         products/ocp4/profiles/pci-dss-node.profile \
         products/ocp4/profiles/pci-dss.profile \
         products/ocp4/profiles/cis-node.profile \
+        products/ocp4/profiles/cis-vm-extension.profile \
         products/ocp4/profiles/cis.profile \
         products/ocp4/profiles/moderate-node.profile \
         products/ocp4/profiles/moderate.profile \
@@ -41,13 +42,14 @@ RUN if [ "$(uname -m)" == "x86_64" ] || [ "$(uname -m)" == "aarch64" ]; then \
 # OpenShift content for ppc64le and s390x architectures since we're not
 # including any RHCOS profiles on those architectures right now anyway.
 RUN if [ "$(uname -m)" = "x86_64" ] || [ "$(uname -m)" == "aarch64" ]; then \
-        ./build_product ocp4 rhcos4 eks --datastream-only; \
+        ./build_product ocp4 rhcos4 eks --datastream --cel-content=ocp4; \
         elif [ "$(uname -m)" = "ppc64le" ]; then \
-        ./build_product ocp4 rhcos4 --datastream-only; \
-        else ./build_product ocp4 --datastream-only; \
+        ./build_product ocp4 rhcos4 --datastream --cel-content=ocp4; \
+        else ./build_product ocp4 --datastream --cel-content=ocp4; \
         fi
 
 FROM registry.access.redhat.com/ubi8/ubi-micro:latest
 
 WORKDIR /
 COPY --from=builder /content/build/ssg-*-ds.xml .
+COPY --from=builder /content/build/*-cel-content.yaml .

Dockerfiles/quay_publish

@@ -3,10 +3,11 @@ FROM fedora:38 as builder
 RUN dnf -y install cmake make git /usr/bin/python3 python3-pyyaml python3-jinja2 openscap-utils
 RUN git clone --depth 1 https://github.com/ComplianceAsCode/content
 WORKDIR /content
-RUN ./build_product --datastream-only --debug ocp4 rhcos4 eks
+RUN ./build_product --datastream --debug ocp4 rhcos4 eks --cel-content=ocp4
 
 FROM registry.access.redhat.com/ubi8/ubi-minimal
 WORKDIR /
 COPY --from=builder /content/build/ssg-ocp4-ds.xml .
 COPY --from=builder /content/build/ssg-rhcos4-ds.xml .
 COPY --from=builder /content/build/ssg-eks-ds.xml .
+COPY --from=builder /content/build/ocp4-cel-content.yaml .

README.md

@@ -41,6 +41,12 @@ profiles.  These are meant to be run on machines to put them into
 compliance.  We recommend using other formats but understand that for
 some deployment scenarios bash is the only option.
 
+*"CEL content"* refers to compliance content using the Common Expression Language (CEL)
+for Kubernetes and OpenShift platforms. CEL content is generated as YAML files and is
+designed for native Kubernetes resource evaluation through the compliance-operator,
+without requiring shell access to nodes. This format is used for platform-level
+compliance checks on container orchestration systems.
+
 ### Why?
 
 We want multiple organizations to be able to efficiently develop security

applications/openshift-virtualization/group.yml

@@ -0,0 +1,7 @@
+documentation_complete: true
+
+title: 'OpenShift Virtualization'
+
+description: |-
+    This section contains security recommendations for OpenShift Virtualization
+    (KubeVirt) configuration and virtual machine management.

applications/openshift-virtualization/kubevirt-enforce-trusted-tls-registries/cel/shared.yml

@@ -0,0 +1,17 @@
+check_type: Platform
+
+failure_reason: |-
+    There are registries not using TLS in '.spec.storageImport.insecureRegistries' in
+    the 'kubevirt-hyperconverged' resource.
+
+inputs:
+  - name: hco
+    kubernetes_input_spec:
+      api_version: hco.kubevirt.io/v1beta1
+      resource: hyperconvergeds
+      resource_name: kubevirt-hyperconverged
+      resource_namespace: openshift-cnv
+
+expression: |-
+  !has(hco.spec.storageImport) ||
+  hco.spec.storageImport.insecureRegistries.size() == 0

applications/openshift-virtualization/kubevirt-enforce-trusted-tls-registries/rule.yml

@@ -0,0 +1,28 @@
+documentation_complete: true
+
+title: 'Only Trusted Registries Using TLS Can Be Used'
+
+description: |-
+    By only pulling container images from trusted registries using TLS, organizations
+    can reduce the risk of introducing unknown vulnerabilities or malicious
+    software into their systems. This helps ensure that their applications and systems
+    remain secure and stable. All container image registries used by KubeVirt should
+    require TLS connections to protect the integrity and authenticity of images.
+
+rationale: |-
+    When the <tt>.spec.storageImport.insecureRegistries</tt> field contains entries in
+    the <tt>kubevirt-hyperconverged</tt> resource, KubeVirt is configured to allow
+    connections to container registries that do not use TLS encryption. This creates
+    a significant security risk as images could be intercepted or tampered with during
+    transit. Man-in-the-middle attacks could result in malicious images being pulled
+    and executed within virtual machines. To maintain security, only registries using
+    TLS should be permitted, and the insecureRegistries list should be empty.
+
+severity: medium
+
+ocil_clause: 'insecure registries are configured'
+
+ocil: |-
+    Run the following command to check for insecure registries:
+    <pre>$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.storageImport.insecureRegistries}'</pre>
+    The output should be empty or the field should not exist.

applications/openshift-virtualization/kubevirt-no-permitted-host-devices/cel/shared.yml

@@ -0,0 +1,26 @@
+check_type: Platform
+
+failure_reason: |-
+    The '.spec.permittedHostDevices' field is set in the 'kubevirt-hyperconverged'
+    resource, allowing host devices to be used by virtualization workloads.
+
+inputs:
+  - name: hcoList
+    kubernetes_input_spec:
+      api_version: hco.kubevirt.io/v1beta1
+      resource: hyperconvergeds
+
+expression: |
+  hcoList.items.filter(h,
+      h.metadata.name == 'kubevirt-hyperconverged' &&
+      h.metadata.namespace == 'openshift-cnv'
+  ).size() == 1 &&
+  hcoList.items.filter(h,
+      h.metadata.name == 'kubevirt-hyperconverged' &&
+      h.metadata.namespace == 'openshift-cnv'
+  ).all(h,
+      !has(h.spec.permittedHostDevices) ||
+      h.spec.permittedHostDevices == null ||
+      (has(h.spec.permittedHostDevices.pciHostDevices) && size(h.spec.permittedHostDevices.pciHostDevices) == 0) &&
+      (has(h.spec.permittedHostDevices.mediatedDevices) && size(h.spec.permittedHostDevices.mediatedDevices) == 0)
+  )

applications/openshift-virtualization/kubevirt-no-permitted-host-devices/rule.yml

@@ -0,0 +1,31 @@
+documentation_complete: true
+
+title: 'KubeVirt Must Not Permit Host Devices'
+
+description: |-
+    Host devices should not be permitted to virtualization workloads unless
+    absolutely necessary for workload execution. Allowing host devices provides
+    direct access to host hardware, which can introduce security risks including
+    unauthorized access to sensitive hardware resources, potential for privilege
+    escalation, and bypass of virtualization security boundaries.
+
+    By default, no host devices should be trusted or permitted for use by
+    virtualization workloads.
+
+rationale: |-
+    The <tt>.spec.permittedHostDevices</tt> field in the <tt>kubevirt-hyperconverged</tt>
+    resource controls which host devices can be used by virtualization workloads.
+    Permitting host devices allows virtual machines to bypass virtualization boundaries
+    and directly access host hardware, which introduces significant security risks.
+    This can lead to unauthorized access to sensitive hardware resources, privilege
+    escalation opportunities, and potential compromise of the host system. Unless
+    explicitly required, no host devices should be permitted.
+
+severity: medium
+
+ocil_clause: 'permittedHostDevices are configured in kubevirt-hyperconverged'
+
+ocil: |-
+    Run the following command to check the HyperConverged configuration:
+    <pre>$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.permittedHostDevices}'</pre>
+    The output should be empty or show empty lists for both <tt>pciHostDevices</tt> and <tt>mediatedDevices</tt>.

applications/openshift-virtualization/kubevirt-no-vms-overcommitting-guest-memory/cel/shared.yml

@@ -0,0 +1,21 @@
+check_type: Platform
+
+failure_reason: |-
+    The '.spec.template.spec.domain.resources.overcommitGuestOverhead' field exists and is
+    set to "true" in the 'VirtualMachine' resource, allowing VMs to
+    overcommit KubeVirt's memory which may lead to guests crashing and
+    interrupting workloads causing malfunctions.
+
+inputs:
+  - name: vms
+    kubernetes_input_spec:
+      api_version: kubevirt.io/v1
+      resource: VirtualMachine
+
+expression: |
+  vms.all(h,
+      !has(h.spec.template.spec.domain.resources) ||
+      !has(h.spec.template.spec.domain.resources.overcommitGuestOverhead) ||
+      (has(h.spec.template.spec.domain.resources.overcommitGuestOverhead) &&
+       h.spec.template.spec.domain.resources.overcommitGuestOverhead == false)
+  )