vMCP: Load authz config from ConfigMap (policies + primaryUpstreamProvider)

[tgrunnagle]

Background

pkg/vmcpconfig/converter.go has two TODOs covering the configMap-sourced authz path on VirtualMCPServer:

• converter.go:192 — TODO: Load policies from ConfigMap if Type is "configMap"
• converter.go:210 — TODO: load primaryUpstreamProvider from configMap

Today, both TODOs mean a VirtualMCPServer with spec.incomingAuth.authzConfig.type: configMap silently produces a vMCP runtime that has no Cedar middleware installed (the factory at pkg/vmcp/auth/factory/incoming.go:88 requires len(cfg.Authz.Policies) > 0). And there is no way for configMap users to override the auto-selected primary upstream provider, because that field lives on InlineAuthzConfig only.

Tasks

• Extract a shared loader (e.g. in cmd/thv-operator/pkg/controllerutil/) that reads + parses the policy ConfigMap. The MCPServer/runner path (AddAuthzConfigOptions) and the vMCP converter should both call it. The loader should return policies + any primary-upstream-provider configuration.
• Wire the converter: when Type == \"configMap\", call the loader, populate incoming.Authz.Policies (and PrimaryUpstreamProvider if applicable). Fail closed on missing/malformed/empty configMap.
• Decide where primaryUpstreamProvider lives for configMap users:
  • Option A — parse it from the policy ConfigMap body (mirrors inline shape, but validator must read the configMap to validate).
  • Option B — lift PrimaryUpstreamProvider from InlineAuthzConfig to AuthzConfigRef so it lives on the spec and is source-agnostic. Validator stays simple. Recommended.
• Status condition parity: add ConditionReasonAuthzConfigMapNotFound to virtualmcpserver_types.go (already exists on MCPRemoteProxy at mcpremoteproxy_types.go:336).
• Update the validator: drop the inline-only assumption in AuthzConfigRef.ExplicitPrimaryUpstreamProvider() once the schema decision lands.
• Tests: converter cases (success, missing CM, missing key, empty value, malformed YAML); validator case for configMap with explicit provider.

Discovered via

• PR Expose explicit primaryUpstreamProvider for Cedar authz on VirtualMCPServer #5199 review (consensus comment, finding F5).
• See also follow-up discussion in PR Expose explicit primaryUpstreamProvider for Cedar authz on VirtualMCPServer #5199 about vMCP not loading the configMap authz today.

Acceptance criteria

• A VirtualMCPServer with authzConfig.type: configMap and a valid policy ConfigMap deploys with Cedar middleware installed and policies enforced.
• Bad/missing configMaps fail at admission with a clear status condition (parallel to MCPRemoteProxy).
• ConfigMap users can pin a primary upstream provider via the schema decision above.