What needs documentation?
The Manage connectors page says discovery picks up MCP servers running in the cluster and that activating a connector performs an endpoint check. It does not explain the operator-side network prerequisite that makes those discovered in-cluster endpoints pass the check.
Document the complete discovery-to-serving path:
- Discovery returns an in-cluster Service endpoint and recommends
allow_private_ips: true for that candidate.
allow_private_ips alone does not authorize Enterprise Manager's verification dial to arbitrary private addresses.
- The platform operator must configure
enterprise-manager.directory.connectorVerification.allowedPrivateRanges with the cluster ranges that discovered endpoints may use.
- For Kubernetes Service endpoints, the value must include the cluster's actual Service CIDR. Operators should derive it from the target cluster rather than copy a kind-specific default.
- Without the allowlist, connector creation can succeed while the connector is persisted in
failure; only available connectors are served.
- After fixing the allowlist, an existing failed connector must be updated/re-saved to trigger verification again. A Helm upgrade alone does not re-check persisted rows.
- A newly available connector still needs directory-group grants before non-admin users can see it.
Include a values example and a verification/troubleshooting sequence that checks connector status after admission.
Context and references
The platform's operator-allowlist design was implemented by:
https://github.com/stacklok/stacklok-enterprise-platform/issues/3644
The current public API schema documents that the discovery result's allow_private_ips value is only a recommendation, but it does not lead operators to the Helm allowlist or explain why a successful create remains unserved.
Relevant source pages:
docs/connector-gateway/connectors.mdx
docs/platform/enterprise-platform/configure-connector-gateway.mdx
docs/platform/enterprise-platform/deployment.mdx
static/api-specs/enterprise-manager-api.json
Use case
As a platform operator importing MCP servers discovered in Kubernetes, I need to authorize the correct private cluster range and know how to recover failed verification, so that discovered connectors become available without weakening the SSRF boundary or hardcoding a distribution-specific CIDR.
What needs documentation?
The Manage connectors page says discovery picks up MCP servers running in the cluster and that activating a connector performs an endpoint check. It does not explain the operator-side network prerequisite that makes those discovered in-cluster endpoints pass the check.
Document the complete discovery-to-serving path:
allow_private_ips: truefor that candidate.allow_private_ipsalone does not authorize Enterprise Manager's verification dial to arbitrary private addresses.enterprise-manager.directory.connectorVerification.allowedPrivateRangeswith the cluster ranges that discovered endpoints may use.failure; onlyavailableconnectors are served.Include a values example and a verification/troubleshooting sequence that checks connector
statusafter admission.Context and references
The platform's operator-allowlist design was implemented by:
https://github.com/stacklok/stacklok-enterprise-platform/issues/3644
The current public API schema documents that the discovery result's
allow_private_ipsvalue is only a recommendation, but it does not lead operators to the Helm allowlist or explain why a successful create remains unserved.Relevant source pages:
docs/connector-gateway/connectors.mdxdocs/platform/enterprise-platform/configure-connector-gateway.mdxdocs/platform/enterprise-platform/deployment.mdxstatic/api-specs/enterprise-manager-api.jsonUse case
As a platform operator importing MCP servers discovered in Kubernetes, I need to authorize the correct private cluster range and know how to recover failed verification, so that discovered connectors become available without weakening the SSRF boundary or hardcoding a distribution-specific CIDR.