Skip to content

[Gap]: Document in-cluster connector discovery network prerequisites and recovery #1161

Description

@danbarr

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:

  1. Discovery returns an in-cluster Service endpoint and recommends allow_private_ips: true for that candidate.
  2. allow_private_ips alone does not authorize Enterprise Manager's verification dial to arbitrary private addresses.
  3. The platform operator must configure enterprise-manager.directory.connectorVerification.allowedPrivateRanges with the cluster ranges that discovered endpoints may use.
  4. 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.
  5. Without the allowlist, connector creation can succeed while the connector is persisted in failure; only available connectors are served.
  6. 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.
  7. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or requestneeds-triageIssue needs initial triage by a maintainer

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions