Repository navigation
[Gap]: Document the complete Connector Gateway deployment contract #1159
Description
What needs documentation?
The Configure the Connector Gateway page currently shows only:
global.stacklok.connectorGateway.enabledglobal.stacklok.connectorGatewayIdglobal.stacklok.authServerIssuer
That is not enough to deploy a working Connector Gateway. The chart requires a coupled set of auth-server, incoming-auth, directory, key-management, storage, corporate-IdP, and Enterprise Manager values. Operators currently discover them one failure at a time from Helm errors, pod logs, and the chart's very long values.yaml comments.
Add a complete, task-oriented configuration path that covers at least:
vmcpConfig.incomingAuth.type: oidc, issuer, audience/resource, and how those values must match the auth server'sallowed_audiences.enterpriseConfig.authServer, including its schema, upstream behavior, storage contract, and the fact that auth-less mode is not supported.kekandauthServerKeys, including the production recommendation to use existing Secrets rather than render-unstable generated values.enterpriseConfig.directory.addrand binding claims.- The two supported Directory transport arms:
- production TLS, projected ServiceAccount token, caller issuer/audience, and subject allowlists on Enterprise Manager;
- the development-only cleartext configuration, which currently requires matching client and server flags.
- The corporate primary IdP's audience/client requirements for both cloud-ui and the Connector Gateway control plane.
- The Enterprise Manager platform-admin role/binding required to use the admin connector/directory endpoints. The current directory landing page says "The platform admin grant covers" this work but does not show how to create that grant or identify
admin.enterprise.stacklok.com. - A verification sequence that tests login, gateway registration, an authenticated control-plane call, and the data-plane MCP endpoint separately.
Prefer one complete secure example, followed by focused alternatives, rather than making readers assemble fragments from component chart comments.
Context and references
This gap surfaced while moving stacklok-enterprise-demo-sandbox to Stacklok Enterprise Platform v0.17.0.
Related platform issues found during the same deployment:
- https://github.com/stacklok/stacklok-enterprise-platform/issues/4307
- https://github.com/stacklok/stacklok-enterprise-platform/issues/4309
- https://github.com/stacklok/stacklok-enterprise-platform/issues/4312
Relevant source pages:
docs/platform/enterprise-platform/configure-connector-gateway.mdxdocs/platform/enterprise-platform/deployment.mdxdocs/platform/enterprise-platform/configure-identity.mdxdocs/platform/enterprise-directory/index.mdx
Use case
As a platform operator, I need to enable Connector Gateway from a single supported checklist and understand which values form one contract across the umbrella chart, so that a successful Helm install produces a usable login, control plane, and MCP data plane without iterative crash-loop debugging.
Activity
danbarr commentedon Oct 9, 2026
Most of the original deployment gap is covered by #1180 and the now-merged #1220. The current guide includes incoming OIDC issuer/audience matching, the embedded authorization server's schema and Redis storage, existing Secrets for key material, directory addressing and binding claims, TLS and development-only cleartext transport, ServiceAccount subject allowlists, and endpoint publishing. #1220 also adds separate checks for gateway registration, OAuth discovery, an authenticated control-plane request, and browser login plus an MCP tool call through the linked quickstart.
The remaining work is:
admin.enterprise.stacklok.com, and show how to verify the grant. Link it from the directory landing page, console prerequisites, and gateway configuration guide. Distinguish this authorization grant from the PostgreSQLBYPASSRLSrole already documented for the admin database connection.global.stacklok.primaryIdp.clientId, the console's OAuth client, andclientClaimrelate; document the actual issuer, audience, and client-claim validation each endpoint performs. Include a worked configuration and token check so operators can obtain the<CORPORATE_ACCESS_TOKEN>used by the new verification step and diagnose a401. Keep this separate from the gateway-issued token and/gw/mcpaudience used by MCP clients.connector-gateway.directoryTLS.audiencemust match the Enterprise Manager'sgrpc.callerAuth.callerAudience. State the matching defaults and show the paired overrides when an operator changes them.These are the remaining acceptance items for this issue. The endpoint publishing/verification and in-cluster discovery network/recovery work is covered by #1220, which closes #1217 and #1161.