feat: Add auth-headers cluster provider for dynamic multi-tenant Kubernetes access #509
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a new
auth-headerscluster provider strategy that enables multi-tenant Kubernetes MCP server deployments where cluster connection details and authentication credentials are provided via HTTP headers on a per-request basis.Summary
The auth-headers provider allows clients to connect to different Kubernetes clusters dynamically without server-side configuration or stored credentials. All cluster connection details (server URL, CA certificate, authentication) are provided in request headers, enabling true zero-trust and multi-tenant architectures.
Documentation
Complete documentation added in
docs/AUTH_HEADERS_PROVIDER.md.Custom Headers
Clients must provide these headers with each request:
Required:
kubernetes-server- Kubernetes API server URLkubernetes-certificate-authority-data- Base64-encoded CA certificateAuthentication (one required):
kubernetes-authorization- Bearer token, ORkubernetes-client-certificate-data+kubernetes-client-key-data- Client cert/key pairOptional:
kubernetes-insecure-skip-tls-verify- Set totrueto skip TLS verificationBackward Compatibility
✅ Fully backward compatible - existing providers unchanged
✅ No breaking changes to existing APIs
✅ New provider is opt-in via configuration
Example usage (Python):
Related Issues