Fixed
- (deps) Update module github.com/go-jose/go-jose/v4 to v4.1.5 in #1139 by @renovate[bot]
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.19...v5.7.20
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.19...v5.7.20
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.18...v5.7.19
modelManager.networkPolicy.egress (fqdns, cidrs, both empty): further destinations of model-manager on 443 whatever the backend — a private identity provider, a model mirror — the same knob agentManager.networkPolicy.egress already is. cilium: FQDN selectors next to the Hugging Face names and the Ollama endpoint, blocks as toCIDR; kubernetes: the blocks as ipBlocks (names are ignored, the flavor has no FQDN selector). networkPolicy.additionalEgressCIDRs / additionalEgressFQDNs now apply to the model-manager cilium egress for the ollama backend too (they used to render only for the kserve backend; the kubernetes flavor always applied them).agent-platform.idpHosts helper in the connectivity chart: the hosts a service that validates tokens itself reaches at its identity provider, from the OAuth provider and the issuer URL — the Dex issuer host, or Google’s accounts.google.com, www.googleapis.com and oauth2.googleapis.com. agent-platform.idpEgress.cilium takes provider next to issuerUrl and renders one toFQDNs rule over those hosts.oauth.provider: google. The IdP egress rule named the issuer host by FQDN and the per-component issuer helpers deliberately return nothing for the google provider, so a Google-backed install rendered no name at all: mcp-oauth’s JWKS fetch (www.googleapis.com/oauth2/v3/certs), userinfo fallback and discovery (accounts.google.com) timed out under policyEnforcementMode: always, muster’s forwarded-token sessions failed and the operator had to add the three hosts to agentManager.networkPolicy.egress.fqdns and open world:443 for model-manager by hand (agent-platform-standalone#106). The rule now derives the hosts from the provider: accounts.google.com (discovery, authorization), www.googleapis.com (JWKS, userinfo) and oauth2.googleapis.com (token, revocation) — the endpoints mcp-oauth’s google provider dials — next to the unchanged cluster entity on 443/10443. The dex render is byte-identical; the kubernetes flavor already opened every public destination on 443 while OAuth is on. make verify-managers asserts both providers and the new egress knob.modelManager.networkPolicy.ingress.additionalPeers and agentManager.networkPolicy.ingress.additionalPeers (default []), in both charts: extra callers the model-manager / agent-manager ingress policies admit on the Service port next to the agentgateway data plane and muster — a list of pod label maps (matchLabels) in the release namespace, rendered as fromEndpoints entries with io.kubernetes.pod.namespace pinned to the release namespace (cilium) or as podSelector entries (kubernetes). A non-empty list counts as a platform caller, so the no-caller placeholder peer does not render next to it; an item that is not a non-empty label map fails the render. For an umbrella that runs a portal next to the managers (the standalone chart’s Backstage, which patched the peer into its generated copies until now). make verify-managers covers it. No installation needs to act: the default render is unchanged.Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.3.0...v3.3.1
components.model-manager (model-manager, model inventory / pull / load / unload / delete and kagent ModelConfig wiring on an Ollama or KServe backend) and components.agent-manager (agent-manager, the agent write surface: kagent agents as Flux HelmReleases of the agent chart), each as REST and MCP through muster’s own MCPServer CR and each acting as the user (OAuth 2.1 resource server, forwarded id_tokens, downstream OAuth to the Kubernetes API, no ServiceAccount RBAC). The model-manager: / agent-manager: blocks are forwarded to the component releases; the modelManager: / agentManager: blocks drive the wiring the connectivity chart renders for them — the agentgateway route and JWT policy (route.*, the kagent controller route’s shape), the network policies in both flavors (ingress from the data plane, muster and the kubelet’s probes; egress to DNS, the Kubernetes API, the identity provider, the Ollama endpoint or the Hugging Face Hub, the agent chart’s registry and GitHub) and render-time guards (backend, endpoint, KServe and Flux APIs, kagent on and same namespace, muster for the MCPServer CR, the OAuth inputs, route mode / hostname / parentRef / JWKS egress). make verify-managers covers them; examples/customer-bom.yaml pins both. No installation needs to act: both components are off and the default render is unchanged.agent-platform.dnsEgressWithProxy, agent-platform.urlHost and agent-platform.idpEgress.cilium helpers in the connectivity chart: a DNS egress rule with Cilium’s proxy clause for policies that select destinations by name, and the egress a platform service needs to reach the login identity provider (by name on 443, plus the cluster entity on 443/10443 for an issuer behind an in-cluster Gateway).spec.auth.forwardToken, or tokenExchange.enabled) is no longer registered globally with a token-less client when its backend answers muster’s connection probe anonymously — for example the old, anonymous pod during a rollover to an OAuth-protected release. The decision to handle a server per session now comes from the server’s own definition rather than from the aggregator registry entry that only exists after a registration (and is gone while the reconciler restarts a changed server): the service treats the accepted anonymous probe like a 401 — the probe client is closed, the server reports Auth Required, and every session connects with the caller’s own token — and the aggregator refuses to attach a shared client to such a server on any path. Previously the shared client 401-looped once the protected pod took over and every session’s tool call failed with authorization required until muster was restarted. A behavioral scenario (oauth-sso-forwarding-anonymous-backend) covers both a server created with forwardToken and one that gains it through core_mcpserver_update. (#1135)starting event from the same start is still queued for the aggregator’s event handler; the handler declines to deregister a server whose entry says auth_required, but that check and the removal were two steps and the registration could land in between (the RegisteredAt guard did not catch it when the entry was created before the deregistration was timestamped). core_auth_login then answered “Server not found” until the periodic pending-auth heal ran, up to 5 s later. State-change-driven deregistration now decides under the registry lock and keeps entries that require per-session authentication; the paths for a deleted service are unchanged.Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.16...v5.7.17
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.15...v5.7.16
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.14...v5.7.15