Improve docs and style guides with CEL rules info

Author: yuumasato

docs/manual/developer/03_creating_content.md

@@ -26,7 +26,7 @@ build files/configuration, etc.
 </tr>
 <tr class="odd">
 <td><p><code>applications</code></p></td>
-<td><p>Contains security content for applications such as OpenShift or OpenStack. Contains rules, OVAL checks, Ansible tasks, Bash remediations, etc.</p></td>
+<td><p>Contains security content for applications such as OpenShift or OpenStack. Contains rules, OVAL checks, CEL checks, Ansible tasks, Bash remediations, etc. For Kubernetes/OpenShift CEL rules, see <a href="12_cel_content.md">CEL Content</a>.</p></td>
 </tr>
 <tr class="even">
 <td><p><code>shared</code></p></td>

docs/manual/developer/04_style_guide.md

@@ -274,6 +274,90 @@ Rules sections must be in the following order, if they are present.
     * Must be a valid rule id
 * `template`
 
+#### CEL Rule Sections
+
+CEL (Common Expression Language) rules are used for Kubernetes/OpenShift compliance checks.
+CEL rules use different fields than traditional OVAL-based rules.
+
+CEL rule sections must be in the following order, if present:
+
+* `documentation_complete`
+* `title`
+* `description` (HTML Like)
+* `rationale` (HTML Like)
+* `severity`
+* `identifiers` (Optional)
+    * Keys must be in alphabetical order
+* `references` (Optional)
+    * Keys must be in alphabetical order
+* `ocil_clause` (Optional)
+* `ocil` (HTML Like, Optional)
+* `failure_reason` (Optional)
+    * Must be a block
+    * Must describe the condition when the check fails
+* `check_type`
+    * Must be `Platform` for Kubernetes/OpenShift checks
+* `scanner_type`
+    * Must be `CEL` for CEL rules
+* `inputs`
+    * Must be a list of at least one input
+    * Each input must have:
+        * `name` - Variable name used in the CEL expression
+        * `kubernetes_input_spec` - Kubernetes resource specification
+            * `api_version` - Kubernetes API version (e.g., `v1`, `apps/v1`)
+            * `resource` - Resource type in plural form (e.g., `pods`, `deployments`)
+            * `resource_name` (Optional) - Specific resource name to query
+            * `resource_namespace` (Optional) - Specific namespace to query
+* `expression`
+    * Must be a valid CEL expression that evaluates to boolean
+    * Must use variables defined in `inputs`
+    * Should use `has()` to check for field existence before accessing
+    * Should be formatted for readability using multi-line block syntax for complex expressions
+
+CEL rules must NOT include:
+* `template` field (CEL rules don't use templates)
+* `platform` field (implied by `scanner_type: CEL`)
+
+Example CEL rule structure:
+
+```yaml
+documentation_complete: true
+
+title: 'Rule Title in Title Case'
+
+description: |-
+    Description of what the rule checks.
+
+rationale: |-
+    Why this rule matters for security/compliance.
+
+severity: medium
+
+scanner_type: CEL
+
+check_type: Platform
+
+expression: |-
+    resource.spec.enabled == true &&
+    has(resource.spec.field) &&
+    resource.spec.field == "expected_value"
+
+inputs:
+  - name: resource
+    kubernetes_input_spec:
+      api_version: v1
+      resource: configmaps
+      resource_name: my-config
+      resource_namespace: default
+
+ocil: |-
+    Run the following command:
+    <pre>$ oc get configmap my-config -n default</pre>
+
+failure_reason: |-
+    The resource is not properly configured.
+```
+
 ### Group
 
 This section describes the style guide around the `group.yml` files.
@@ -354,21 +438,27 @@ Control sections must be in the following order, if they are present.
 
 #### Profile Sections
 
-Control sections must be in the following order, all sections are required unless otherwise noted.
+Profile sections must be in the following order, all sections are required unless otherwise noted.
 
 * `documentation_complete`
-* `id`
-* `metadata`
+* `metadata` (Optional)
     * `reference`
     * `version`
     * `SMEs`
 * `title`
     * Shall be short and descriptive
 * `description` (HTML-Like)
+* `platform` (Optional)
+    * Must be a valid platform identifier (e.g., `ocp4`, `rhel9`)
+* `scanner_type` (Optional)
+    * Must be `CEL` for CEL profiles
+    * CEL profiles can only select CEL rules
+    * CEL profiles are excluded from XCCDF/OVAL generation
 * `extends` (Optional)
     * Must be valid id of another profile id
 * `selections`
     * Must be valid rule ids
+    * For CEL profiles, must only contain CEL rule ids (using hyphens, not underscores)
 
 ## Remediation
 

docs/manual/developer/06_contributing_with_content.md

@@ -668,12 +668,19 @@ Tips:
 
 ### Checks
 
-Checks are used to evaluate a Rule. There are two types of check content
-supported by ComplianceAsCode: OVAL and SCE. Note that OVAL is standardized
-by NIST and has better cross-scanner support than SCE does. However, because
-SCE can use any language on the target system (Bash, Python, ...) it is much
-more flexible and general-purpose than OVAL. This project generally encourages
-OVAL unless it lacks support for certain features.
+Checks are used to evaluate a Rule. There are three types of check content
+supported by ComplianceAsCode: OVAL, CEL, and SCE.
+
+* **OVAL** (Open Vulnerability and Assessment Language) - Standardized by NIST with better cross-scanner support. Used for traditional operating system compliance checks (file system, processes, packages). Generally the preferred choice for OS-level checks.
+
+* **CEL** (Common Expression Language) - Used for Kubernetes and OpenShift platform compliance checks. CEL rules evaluate Kubernetes API resources without requiring shell access to nodes. See [CEL Content](12_cel_content.md) for complete documentation on creating CEL rules.
+
+* **SCE** (Script Check Engine) - Can use any language on the target system (Bash, Python, ...) making it more flexible and general-purpose than OVAL, but with less cross-scanner support.
+
+This project generally encourages using:
+- OVAL for Linux/OS checks
+- CEL for Kubernetes/OpenShift platform checks
+- SCE only when OVAL lacks support for certain features
 
 #### OVAL Check Content
 
@@ -946,6 +953,70 @@ means:
 </tbody>
 </table>
 
+### CEL Check Content
+
+[CEL](https://github.com/google/cel-spec) (Common Expression Language) is a mechanism
+for evaluating Kubernetes and OpenShift API resources for compliance checking. CEL checks
+are used by the [compliance-operator](https://github.com/ComplianceAsCode/compliance-operator)
+to perform platform-level compliance checks without requiring shell access to nodes.
+
+CEL rules are defined directly in the `rule.yml` file using specialized fields:
+
+* `scanner_type: CEL` - Marks the rule as a CEL rule
+* `check_type: Platform` - Indicates this is a platform-level check
+* `expression` - The CEL expression that evaluates to boolean (true=pass, false=fail)
+* `inputs` - List of Kubernetes resources to evaluate
+* `failure_reason` - Optional custom failure message
+
+Within a rule's `inputs` section, each input specifies a Kubernetes resource using `kubernetes_input_spec`:
+
+* `api_version` - Kubernetes API version (e.g., `v1`, `apps/v1`)
+* `resource` - Resource type in plural form (e.g., `pods`, `deployments`)
+* `resource_name` - Optional: specific resource name to query
+* `resource_namespace` - Optional: specific namespace to query
+
+**Important notes:**
+
+* CEL rules are **excluded** from XCCDF/OVAL DataStreams
+* CEL rules generate a separate `${PRODUCT}-cel-content.yaml` file
+* CEL profiles can only select CEL rules
+* Rule directory names should use hyphens (Kubernetes naming convention)
+
+For complete documentation on creating CEL rules, see [CEL Content](12_cel_content.md).
+
+Example CEL rule:
+
+```yaml
+scanner_type: CEL
+check_type: Platform
+
+expression: |-
+    resource.spec.replicas >= 3 &&
+    has(resource.spec.template.spec.securityContext) &&
+    resource.spec.template.spec.securityContext.runAsNonRoot == true
+
+inputs:
+  - name: resource
+    kubernetes_input_spec:
+      api_version: apps/v1
+      resource: deployments
+      resource_name: my-app
+      resource_namespace: default
+```
+
+To build CEL content for a product, enable it in the product's `CMakeLists.txt`:
+
+```cmake
+set(PRODUCT "ocp4")
+set(PRODUCT_CEL_ENABLED TRUE)
+ssg_build_product(${PRODUCT})
+```
+
+## Remediations
+
+The following sections describe remediation content. Note that CEL rules do **not** support
+remediation content - they are check-only.
+
 ### Ansible
 
 > **Important**