Skip to content

Watch authz ConfigMaps from VirtualMCPServer#5271

Merged
blkt merged 1 commit into
mainfrom
feat/vmcp-watch-authz-configmap
May 14, 2026
Merged

Watch authz ConfigMaps from VirtualMCPServer#5271
blkt merged 1 commit into
mainfrom
feat/vmcp-watch-authz-configmap

Conversation

@blkt
Copy link
Copy Markdown
Contributor

@blkt blkt commented May 13, 2026

The VirtualMCPServer controller did not watch ConfigMaps referenced by spec.incomingAuth.authzConfig.configMap, so changes to a referenced authz ConfigMap were never observed: the converter was not re-run, the rendered vmcp config.yaml retained stale policies, and the running pod enforced them indefinitely. This matters in particular for the enterprise flow where an external controller rewrites the authz ConfigMap when Cedar policies change.

Add a Watches entry on corev1.ConfigMap with:

  • a mapper that lists VirtualMCPServers in the ConfigMap's namespace and enqueues those whose AuthzConfig.Type is "configMap" and whose ConfigMap.Name matches the changed object
  • a predicate that admits Create and Delete events unconditionally and Update events only when .Data or .BinaryData actually changed, so metadata-only updates (labels, annotations, resourceVersion bumps) do not trigger reconciliation

The watch is functionally meaningful only once #5208 lands and the converter actually resolves ConfigMap-sourced policies; until then the re-reconcile still produces an empty-policy config. Wiring it now unblocks that follow-up without an extra round trip.

Closes #5270

@blkt blkt self-assigned this May 13, 2026
@github-actions github-actions Bot added the size/M Medium PR: 300-599 lines changed label May 13, 2026
@codecov
Copy link
Copy Markdown

codecov Bot commented May 13, 2026

Codecov Report

❌ Patch coverage is 77.77778% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.28%. Comparing base (3dfed71) to head (98ee559).

Files with missing lines Patch % Lines
...or/controllers/virtualmcpserver_authz_configmap.go 87.50% 3 Missing and 2 partials ⚠️
...perator/controllers/virtualmcpserver_controller.go 0.00% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5271      +/-   ##
==========================================
- Coverage   68.32%   68.28%   -0.05%     
==========================================
  Files         618      619       +1     
  Lines       63274    63319      +45     
==========================================
+ Hits        43235    43236       +1     
- Misses      16807    16851      +44     
  Partials     3232     3232              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment thread cmd/thv-operator/controllers/virtualmcpserver_authz_configmap.go
Copy link
Copy Markdown
Contributor

@jhrozek jhrozek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that comment was meant to be a follow-up suggestion, not a blocker

The VirtualMCPServer controller did not watch ConfigMaps referenced by
spec.incomingAuth.authzConfig.configMap, so changes to a referenced
authz ConfigMap were never observed: the converter was not re-run, the
rendered vmcp config.yaml retained stale policies, and the running pod
enforced them indefinitely. This matters in particular for the
enterprise flow where an external controller rewrites the authz
ConfigMap when Cedar policies change.

Add a Watches entry on corev1.ConfigMap with:

  * a mapper that lists VirtualMCPServers in the ConfigMap's namespace
    and enqueues those whose AuthzConfig.Type is "configMap" and whose
    ConfigMap.Name matches the changed object
  * a predicate that admits Create and Delete events unconditionally
    and Update events only when .Data or .BinaryData actually changed,
    so metadata-only updates (labels, annotations, resourceVersion
    bumps) do not trigger reconciliation

The watch is functionally meaningful only once #5208 lands and the
converter actually resolves ConfigMap-sourced policies; until then the
re-reconcile still produces an empty-policy config. Wiring it now
unblocks that follow-up without an extra round trip.

Closes #5270
@blkt blkt force-pushed the feat/vmcp-watch-authz-configmap branch from f8f2c6d to 98ee559 Compare May 14, 2026 08:54
@github-actions github-actions Bot added size/M Medium PR: 300-599 lines changed and removed size/M Medium PR: 300-599 lines changed labels May 14, 2026
@blkt blkt merged commit 4d411ce into main May 14, 2026
72 of 73 checks passed
@blkt blkt deleted the feat/vmcp-watch-authz-configmap branch May 14, 2026 09:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/M Medium PR: 300-599 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

VirtualMCPServer controller should re-reconcile when a referenced authz ConfigMap changes

2 participants