Add MCPAuthzConfig ref-resolution foundation#5559
Merged
Merged
Conversation
Foundation (Stage 1 of #4778's re-derivation) for making spec.authzConfigRef enforce at runtime. Purely additive: no workload controller is wired yet and the inline spec.authzConfig path is untouched. - Add controllerutil ref-helpers in authz_ref.go: GetAuthzConfigForWorkload, ValidateAuthzConfigReady, AddAuthzConfigRefOptions (resolves a referenced MCPAuthzConfig into a runner authz.Config for any registered backend — cedarv1 and httpv1 — via the authorizers factory), and the EnsureAuthzConfigMapFromRef / GenerateAuthzVolumeConfigFromRef materialization helpers mirroring the inline ones. - Export and move BuildFullAuthzConfigJSON from the MCPAuthzConfig controller into controllerutil so both the config controller and the workload controllers share it without an import cycle; the controller now calls the shared helper. - Add the AuthzConfigHash status field to MCPServer, MCPRemoteProxy, and VirtualMCPServer, plus ConditionAuthzConfigRefValidated and reason constants, mirroring the OIDCConfigRef equivalents. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5559 +/- ##
==========================================
- Coverage 70.05% 70.05% -0.01%
==========================================
Files 650 651 +1
Lines 66167 66248 +81
==========================================
+ Hits 46352 46408 +56
- Misses 16459 16476 +17
- Partials 3356 3364 +8 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
- Guard EnsureAuthzConfigMapFromRef with ValidateAuthzConfigReady so the exported helper never materializes a ConfigMap from a config flagged invalid (defense in depth; no extra I/O — the object is already fetched). (F2) - Clarify the authzRefConfigMapName doc comment: the ConfigMap *name* is distinct from the inline path, while the *volume* name and mount path are deliberately shared (inline and ref are mutually exclusive via CRD XValidation, so a workload mounts at most one authz volume). (F3) - Restore the nil data/factory assertions on BuildFullAuthzConfigJSON's error branch. (F5) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
reyortiz3
approved these changes
Jun 18, 2026
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.
Summary
Workloads can reference a shared
MCPAuthzConfigviaspec.authzConfigRef, but today that reference is a runtime no-op — the workload controllers only consume the inlinespec.authzConfig. This is the foundation (stage 1 of finishing the MCPAuthzConfig wiring originally drafted in the now-stale #4778, re-derived against currentv1beta1) that the per-controller wiring will build on. It is purely additive — no controller is wired yet, so there is no behavior change.Part of finishing the MCPAuthzConfig implementation (follow-up to #4777; supersedes the stale #4778).
Medium level
controllerutilref-helpers (authz_ref.go):GetAuthzConfigForWorkload,ValidateAuthzConfigReady,AddAuthzConfigRefOptions(resolves a referencedMCPAuthzConfiginto a runnerauthz.Configfor any registered backend —cedarv1andhttpv1— via the authorizers factory, so MCPServer/MCPRemoteProxy get all backends for free), andEnsureAuthzConfigMapFromRef/GenerateAuthzVolumeConfigFromRefmirroring the inline materialization helpers.BuildFullAuthzConfigJSONfrom theMCPAuthzConfigcontroller intocontrollerutilso the config controller and the workload controllers share one backend-agnostic envelope builder without an import cycle; the controller now calls the shared helper (behavior-preserving).AuthzConfigHashstatus field to MCPServer, MCPRemoteProxy, and VirtualMCPServer, plusConditionAuthzConfigRefValidated+ reason constants, mirroring theOIDCConfigRefequivalents. Regenerated CRD manifests +crd-api.md.Low level
cmd/thv-operator/pkg/controllerutil/authz_ref.goBuildFullAuthzConfigJSONcmd/thv-operator/pkg/controllerutil/authz_ref_test.gocmd/thv-operator/controllers/mcpauthzconfig_controller.goctrlutil.BuildFullAuthzConfigJSON; drop private copy + unused const/importcmd/thv-operator/controllers/mcpauthzconfig_controller_test.gocmd/thv-operator/api/v1beta1/{mcpserver,mcpremoteproxy,virtualmcpserver}_types.goAuthzConfigHashstatus field; condition constants onmcpserver_types.godeploy/charts/operator-crds/**,docs/operator/crd-api.mdType of change
Test plan
task testpasses forcmd/thv-operator/pkg/controllerutil,controllers, andapi/v1beta1BuildFullAuthzConfigJSON/AddAuthzConfigRefOptionsare backend-agnostic (drive a realhttpv1config end-to-end through the factory, not justcedarv1), plus not-found / not-ready error pathstask buildpasses; generated code re-run with no driftSpecial notes for reviewers
Foundation only — intentionally not wired into any reconciler; the inline
spec.authzConfigpath is untouched. The per-controller wiring (MCPServer, MCPRemoteProxy, VirtualMCPServer) lands in follow-up PRs. The backend-agnostic envelope builder is what lets MCPServer/MCPRemoteProxy support bothcedarv1andhttpv1without runtime changes (the proxy runner's authz factory dispatches on type); VirtualMCPServer will be Cedar-only at first (its vMCP runtime authz is currently Cedar-hardcoded — a separately-tracked follow-up).Generated with Claude Code