Add the MCP audience to the gateway provider instead of asking for a second one

[jiaenren]

Stacked on #1344. Removes the last piece of MCP boilerplate a deployer has to write by hand.

Issue #None

The problem

Enabling MCP required a gateway.envoy.jwt.providers entry carrying the MCP resource URL as its audience. In every deployment that entry was a copy of one already present — same issuer, same JWKS URI, same claim, same cluster — differing only in audience, because the relayed upstream token comes from the identity provider already configured for this deployment's own clients.

A minimal values file failed with:

Error: services.mcp.enabled requires at least one gateway.envoy.jwt.providers entry

and the deployer then had to work out five fields, four of which the chart already knew.

The change

Envoy accepts several audiences per provider, so the resource URL is appended to the entry whose issuer matches the one MCP authenticates against. No deployment writes the second entry.

The issuer is derivable: OpenID Connect Discovery defines the configuration URL as the issuer followed by /.well-known/openid-configuration. accessTokenIssuer still overrides it for providers whose access tokens are issued elsewhere, as an application configured for v1-format tokens does.

Two details worth reviewer attention:

• The issuer comparison ignores a trailing slash, since a v1-style issuer carries one and a discovery-derived issuer does not.
• An entry already carrying that audience does not get it twice, so existing values files render unchanged until they drop the duplicate.

Failing to find a provider for that issuer now names the issuer, rather than saying an entry is required — which was the error a deployer hit after supplying one.

What a deployment writes now

services:
  redis:
    serviceName: redis
  mcp:
    enabled: true
    resourceUrl: https://osmo.example.com/mcp
    oidcProxy:
      oidc:
        configUrl: https://idp.example.com/.well-known/openid-configuration
        clientId: <application-id>
      existingSecret:
        name: mcp-oidc          # key: client-secret

The gateway provider it already needs for its own clients now covers MCP too.

Verification

• bazel test //src/service/mcp/... //test/smoke/... passes 76/76
• render-tests.sh passes, with assertions that the audience is appended to the matching provider, that a provider already carrying it does not get it twice, and that an unset issuer resolves through the configuration URL
• Negative-tested by removing the append and confirming the harness fails
• An existing values file renders with its duplicate provider deleted, the audience landing on the entry that remains

Also corrects a stale "either mode" in the deployment guide, left from the direct-mode removal.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d0d57922-c1d3-4902-9dc2-5ff270fa30cd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[jiaenren]

Consolidated into #1342 to reduce the number of PRs in this stack for review.

Adding the MCP audience to the existing gateway provider is the last value a deployer no longer writes.

No content is lost: the cumulative diff of the stack against main is byte-identical to before the consolidation (verified by comparing the resulting tree). Closing this one.