feat(extauth): evaluate verification CEL rules at request time#24
Open
aramase wants to merge 1 commit into
Open
feat(extauth): evaluate verification CEL rules at request time#24aramase wants to merge 1 commit into
aramase wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR wires ServiceTokenRequirement.spec.verification.rules (CEL) end-to-end by introducing a shared CEL compile/eval path and executing verification CEL rules at ext-auth request time, with controller-side pre-validation to prevent invalid rules from reaching runtime.
Changes:
- Added
pkg/extauth/celverifyto compile verification CEL rules (withtxtoken/requestvariables) and evaluate them against request-scoped context. - Updated
pkg/extauth/server.goto compile rules at push time, store compiled snapshots atomically, and evaluate compiled CEL duringCheck. - Updated
internal/controllerCEL validation to compile usingcelverify.Compile, plus added unit/e2e tests covering compile/eval and request-path behavior.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/extauth/server.go | Compiles verification CEL at rule-push time, stores compiled snapshot atomically, evaluates CEL during request verification. |
| pkg/extauth/server_test.go | Adds request-path tests for allow/deny, request variables, and handling of invalid CEL in snapshots. |
| pkg/extauth/celverify/cel.go | New shared CEL compilation + evaluation implementation for verification rules. |
| pkg/extauth/celverify/cel_test.go | Unit tests for CEL compile/eval behavior (syntax, type checks, denial semantics, runtime errors). |
| internal/controller/controller.go | Switches verification CEL validation to compile against the shared CEL env used by runtime. |
| internal/controller/controller_test.go | Adds tests for controller-side validation failures (syntax/type/unknown vars/empty). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
76a587d to
876ed71
Compare
ServiceTokenRequirement CEL expressions were dead code: extauth checked required scope and tctx field presence but the CEL loop in checkVerificationRules had no evaluator and the controller's pre-validation only checked for empty strings. This wires the existing CELRule type end-to-end: - New pkg/extauth/celverify subpackage compiles rules with cel-go using the documented variables (txtoken, request) and evaluates them against a request-scoped context. Kept import-free of controller and extauth so both sides can share one compile path. - Server.SetVerificationRules now compiles each rule's CEL programs at push time and stores the snapshot in an atomic.Pointer so request handlers swap rule sets without locking. Rules whose CEL fails to compile are dropped and logged; the rest of the snapshot still applies. - checkVerificationRules evaluates the compiled programs after the existing scope/tctx checks and returns a celverify.DeniedError carrying the rule's configured message, which surfaces verbatim in the PermissionDenied response. - The ServiceTokenRequirement reconciler's validateCELRules now invokes celverify.Compile, so syntactically invalid CEL or non-bool expressions flip ConditionReady=False on the owning STR before reaching the runtime (mirrors what TokenPolicyReconciler does for issuance rules).
876ed71 to
0d38e9f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Wires
ServiceTokenRequirement.spec.verification.rules(CEL) end-to-end. Before this PRpkg/extauth/server.go:checkVerificationRuleshad a placeholder loop with a comment saying "CEL rules are evaluated by the ext auth adapter in production / Full CEL evaluation will be added when we integrate with the controller" — every CEL expression was silently ignored, and the controller'svalidateCELRulesonly checked for empty strings.After this PR:
pkg/extauth/celverifysubpackage that compiles CEL programs using the documented variables (txtoken,request) and evaluates them against a request-scoped context. Kept import-free ofinternal/controllerandpkg/extauthso both sides share one compile path.Server.SetVerificationRulescompiles each rule's CEL programs at push time and stores the snapshot in anatomic.Pointer[[]verificationRuleSet]so request handlers swap rule sets without locking. Rules whose CEL fails to compile are dropped and logged; the rest of the snapshot still applies.checkVerificationRulesevaluates the compiled programs after the existing scope/tctx checks and returns acelverify.DeniedErrorcarrying the rule's configured message — which surfaces verbatim in thePermissionDeniedresponse.ServiceTokenRequirementReconciler.validateCELRulesnow invokescelverify.Compile, so syntactically invalid CEL or non-bool expressions flipConditionReady=Falseon the owning STR before the rule ever reaches the runtime. Mirrors whatTokenPolicyReconcilerdoes for issuance rules (PR feat(tts): stream TokenPolicy issuance rules from controller #22).Variables exposed to CEL
Per
api/v1alpha1.VerificationRule.CELdoc-comment:txtoken— TxToken claims, JSON-shaped (txtoken.sub,txtoken.scope,txtoken.tctx.<key>,txtoken.rctx.<key>, etc.).request— HTTP request attributes (request.path,request.method,request.headers["x-foo"]). Header keys are lower-cased to match Envoy normalisation.Tests
pkg/extauth/celverify/cel_test.go: 9 unit tests covering compile success/failure, non-bool output, runtime errors, denied error propagation, first-failing-rule semantics.pkg/extauth/server_test.go: 4 new end-to-end tests throughCheck:txtoken.tctx.classification in [...].txtoken.tctx.classification != "pii"— assertsPermissionDenied+ message + rule name.request.methodaccess (GET allow, DELETE deny).internal/controller/controller_test.go: 4 newvalidateCELRulescases (syntax error, non-bool expression, unknown variable, empty input).All tests pass with
go test -race ./....Out of scope / follow-ups
ServiceTokenRequirement.statusindividually (currently bundled into one Ready=False message). Tracked separately.extauth_verification_cel_denied_total{rule}. Tracked separately.