Skip to content

Design a bounded CEL subset for inline kernel enforcement #243

Description

@JimBugwadia

User outcome

Users combine supported runtime predicates in one expression while retaining synchronous blocking.

Current behavior

Policy-time CEL produces target lists. Per-event monitorFilter runs in userspace after observation and is forbidden in enforce mode. #228 supplies a shared kernel executor, not a userspace request/reply mechanism.

Scope

  • Specify supported expression operators, event fields per hook, cost bounds and compilation to kernel matchers/maps.
  • Reject all expressions that cannot be enforced; never silently downgrade.
  • Compare direct typed matchers with a CEL compiler using real user rules before selecting an implementation.
  • Keep external HTTP/resource calls at policy time.

Acceptance

  • Publish an enforceability matrix and examples covering supported and rejected expressions.
  • Demonstrate equivalence between userspace reference evaluation and kernel execution for the supported subset, plus actual allow/deny behavior.
  • Define verifier/program/map budgets and failure conditions.
  • File bounded implementation slices from the accepted design; no unused production scaffolding.

Dependencies and boundaries

Needs design. Build on concrete matcher work (#189, #65); argument fields depend on #242. It is not a prerequisite for those features.

Validation and completion

  • Table-driven tests pin the stated invariant, including invalid input and policy updates.
  • For code changes: make build and make test; significant changes also require make kind-install and a targeted behavioral check. Pipeline, collector, evaluator, or reporter changes require make smoke-quickstart.
  • Kernel changes use the pinned BPF builder, generated-artifact verification, verifier loading, and allowed/denied behavior tests on supported hook paths.
  • Update DESIGN, development guidance where affected, and the RuntimePolicy reference and limits. Every rejected user rule must reach an operator log and policy condition; count every observation drop. Preserve the reporter redaction boundary.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority/P3Low: refactor, cleanup or speculative

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions