fix: validate muster CRDs via discovery API instead of namespaced list#574
Merged
fix: validate muster CRDs via discovery API instead of namespaced list#574
Conversation
The previous CRD validation probe in the Kubernetes-backed muster client
listed `MCPServer` resources in the hard-coded `default` namespace. When
muster runs with namespace-scoped RBAC -- a `Role` limited to its own
namespace, as is typical for multi-tenant Helm deployments -- the probe
returned `Forbidden`, the constructor wrapped it as "MCPServer CRD not
available", and `NewMusterClient` silently fell back to filesystem mode.
Symptom from the wild: configured `MCPServer` CRs were never auto-started
and the aggregator only exposed the 11 built-in meta-tools. Logs showed:
Found 0 MCPServer definitions for auto-start processing
Deleting MCPServer service: <name>
(The `KubernetesDetector` informer kept emitting reconcile events, but
the orchestrator's `MCPServerManager` was filesystem-backed and returned
NotFound, which the reconciler classified as a delete.)
Switch the probe to the discovery API, which checks that the muster API
group is served and exposes the `MCPServer` kind. Discovery does not
require namespaced list/get permissions on the muster CRDs, so this works
for both cluster-scoped and namespace-scoped RBAC.
Signed-off-by: Timo Derstappen <teemow@gmail.com>
Made-with: Cursor
| // permissions on the muster CRDs in any specific namespace, which is | ||
| // important when muster runs with namespace-scoped RBAC (e.g. a Role limited | ||
| // to its own namespace). | ||
| func (k *kubernetesClient) validateCRDs(ctx context.Context) error { |
Contributor
There was a problem hiding this comment.
ctx is unused.
Is there any reason we are not doing the same validation for the other CRDs like worklow?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
The Kubernetes-backed muster client validates the presence of muster CRDs at startup. The previous probe listed
MCPServerresources in the hard-codeddefaultnamespace and treated any error as "CRD not available". When muster runs with namespace-scoped RBAC (aRolelimited to its own namespace), this probe returnsForbidden, the constructor wraps it as "MCPServer CRD not available", andNewMusterClientsilently falls back to filesystem mode.Symptom in the wild (BWI demo cluster): configured
MCPServerCRs were never auto-started and the aggregator only exposed the 11 built-in meta-tools. Logs:The
KubernetesDetectorinformer kept emitting reconcile events for the existing CR, but the orchestrator'sMCPServerManagerwas filesystem-backed and returned NotFound, which the reconciler classified as a delete -- so the service was never started.Fix
Switch the probe in
validateCRDsto the discovery API (ServerResourcesForGroupVersion). Discovery checks that the muster API group is served and exposes theMCPServerkind without requiring list/get permissions on the muster CRDs in any specific namespace. This works for both cluster-scoped and namespace-scoped RBAC.internal/client/kubernetes_client.godiscovery.DiscoveryInterfacetokubernetesClient.DiscoveryClientfrom the rest config inNewKubernetesClient.validateCRDsto useServerResourcesForGroupVersion(musterv1alpha1.GroupVersion)and look for theMCPServerkind.Test plan
go build ./...go vet ./...,gofmt,goimportsgo test ./...mcp-kubernetesMCPServer is auto-started and tools are surfaced through the aggregator.Made with Cursor