clusters-test: cluster-manager registered by muster, create_cluster dry-run as the signed-in user renders the golden manifests; the portal's create dialog reaches its review step through cluster-manager's MCP tools via muster as the user #58

Lab gap (2026-09-16): the dex-localhost sidecar reached only a fixed list of components — closed by #195 (merged 2026-09-16, released as agentlab v0.49.1)

Finding. The lab patches its dex-localhost sidecar (the socat bridge that lets a pod reach the lab Dex at https://localhost:<dexPort>/dex, HACKS.md U13) through components.<name>.postRenderers, and postrenderers.go named the targets: mcp-kubernetes always, model-manager when platform.modelManager is on, agent-manager when platform.agents is, vm-manager when platform.vmManager is. Two components fall through that list:

• model-manager is on by default in the meta chart since agent-platform 4.24.0 (feat(meta): components.model-manager on by default with zero backends; model-manager >=0.22.0 (#329) agent-platform#479). A lab with platform.modelManager.enabled: false installs it anyway — without the sidecar. Its OIDC discovery dials https://localhost:<dexPort>/dex/.well-known/openid-configuration, gets connection refused on [::1], and the pod crash-loops; the HelmRelease never turns Ready and agentlab up fails after the chart's timeout (agentlab#194 records the symptom).
• cluster-manager exists since 4.26.0 (components.cluster-manager, off by default; feat(meta): components.cluster-manager — the Agent Platform's cluster write surface as a chart component, off by default, in model-manager's mold (giantswarm/agent-platform#316) agent-platform#480). The lab has no toggle and no block for it; turned on through a platform.valuesFiles overlay it gets no sidecar and crash-loops the same way.

The proofs of giantswarm/agent-platform#480 (and the component's issue, #316) worked around both with an overlay that carried the same postRenderers patch by hand — the lab-shape note in that PR's Verification section.

Fix (#195). The sidecar's targets are a rule over the component charts' renders, not a list: every Deployment whose containers are told the lab Dex's localhost address — the issuer URL in an argument (--dex-issuer-url=, the managers) or an environment variable (DEX_ISSUER_URL, mcp-kubernetes) — gets the sidecar, unless the lab already runs it on the host network (muster, Backstage). That is the platform's OAuth contract as the render shows it (global.identity forwarded into the pod), so any manager the chart adds is covered the day it is turned on. agentlab platform renders the values twice (once for the roster, then with the targets), and the values template's roster gained a trailing range that renders components.<name>.postRenderers for a component the lab names no block for (cluster-manager; model-manager with the lab's managed models off). After the install muster is waited for on every selected server that registers an MCPServer of its name. agentlab platform-test reads the same rule off the live Deployments and asserts: sidecar present, rollout complete, every pod Running with 0 restarts, MCPServer Connected.

Proof (in #195). A lab from the branch on chart 4.28.1 with components.cluster-manager.enabled: true in an overlay and nothing else: up selected agent-manager, cluster-manager, mcp-kubernetes and model-manager; all four 2/2 Running with 0 restarts, HelmReleases Ready, MCPServers Connected; cluster-manager audited forwarded_id_token_accepted … validated_issuer: https://localhost:32058/dex; platform-test 9 PASS including the new assertion. The clusters-test scope below (the acceptance criteria) stays open.

Update (Timo, 2026-09-06 — bumblebee-plans#46 grill Q4/Q5): model-manager, agent-manager and cluster-manager keep the logic and speak MCP only — no REST on any manager. The portal calls their tools through muster as the signed-in user, exactly as an agent does. Every write tool has dryRun and mode: apply | commit — apply the manifests directly as the person, or open a pull request as the person through muster's broker grant.

Current plan (Timo, 2026-09-04 — bumblebee-plans#42 grill log agent-platform-kaas/grill-sessions/2026-09-04-open-decisions.md; REST wording replaced 2026-09-06)

The Phase 1 laptop proof: muster lists x_cluster-manager_* (forwardToken, requiredAudiences: kubernetes); create_cluster with dryRun: true as the signed-in user returns manifests equal to the golden render (HelmRelease of release-aws, OCIRepository, values ConfigMap); install_provider dry-run patches the kaas-standalone HelmRelease values; the portal's Clusters page Create dialog reaches its review step through cluster-manager's MCP tools, called through muster as the signed-in user — the same x_cluster-manager_* tools an agent sees; no REST, no agent-platform-backend proxy route (giantswarm/backstage#2247). No templates, no Backstage MCP actions.

Original framing (2026-09-03, superseded where it differs):

Problem

Phase 1 of the epic (giantswarm/giantswarm#37611) adds the cluster template family to the catalog and exposes the same operations to agents as Cluster tools — gs-backend actions in Backstage's MCP actions backend, registered with muster. The lab has to prove everything a laptop can prove before anything rolls out: the templates render, the tools are visible to agents through muster, a dry-run runs as the caller, and the live outcome refuses without an apiserver-accepted token instead of applying under Backstage's own ServiceAccount.

Proposed solution

Extend clusters-test (and backstage-test where the portal is involved), all without a cloud credential:

• Tools through muster: the lab's muster lists create_cluster, edit_cluster, install_provider, enable_agent_platform and delete_cluster from the Backstage MCPServer the standalone chart registers; a dry-run create_cluster as the signed-in lab user (Dex password grant, the pattern the existing headless proofs use) returns the templates' golden manifests; the same call with the live outcome and no apiserver-accepted token returns the refusal naming the missing credential — the proof asserts no object was applied and nothing ran as Backstage's ServiceAccount.
• Template through the portal: drive the create-cluster template with its node-pool step to the review step and the "display manifest" outcome through the scaffolder API, and compare the output with the golden render.
• Destructive marker: delete_cluster is listed with the destructive attribute.

Acceptance criteria

• The five tools are listed through the lab muster with a dryRun input; delete_cluster carries the destructive attribute
• Dry-run output equals the golden render; the live outcome without a token refuses and applies nothing
• The create-cluster template driven headless to display-manifest equals the golden render
• Runs on a laptop without a cloud credential

Related

• Epic: giantswarm/giantswarm#37611
• backstage-catalogs — cluster template family: Cluster template family from the developer portal's create-test-cluster: create (EKS, node-pool step, all pipelines), edit (release, node pools), install provider, delete — each ending in kube:apply or publish:github:pull-request as the signed-in user backstage-catalogs#697
• backstage — Cluster tools actions: Cluster tools: gs-backend actions create-cluster, edit-cluster, install-provider, enable-agent-platform, delete-cluster (each with dryRun) that run the cluster templates as the caller — never a fallback to Backstage's own ServiceAccount backstage#2246
• backstage — MCP endpoint as OAuth resource server: Backstage's MCP actions endpoint as an OAuth resource server muster can register: enable the upstream auth mode, the frontend auth plugin and redirect patterns; find out whether the caller's apiserver-accepted token can reach an action backstage#2245
• standalone chart — Backstage MCPServer registration: Register Backstage's MCP actions endpoint (the Cluster tools) with muster as an MCPServer, OAuth via client-id metadata agent-platform-standalone#112