Adding namespace and tools control arguments

[N0YU0]

Description

Adding an argument (like --namespace) to select a namespace to limit all commands to will be great as a security feature to limit the access to the mcp server to a single namespace even if the kubeconfig has access to multiple (or cluster level access).
Another argument that will help with access control is one to limit tools that can be used with the mcp server (like --exclude-tools or --include-tools). This argument will limit the tools the mcp server can access (like --read-only) but it will enable each user to choose which tools to expose.

My use case is that I want to create an API that will allow users to send questions about their namespaces and will return an answer. The namespace is checked with their permissions but the can ask in the question body to get another namespace's resources. Another thing is I would want to exclude the configuration_view tool as well add the --read-only flag.

[ardaguclu]

@N0YU0 I think this new profile proposal #134 would mitigate some of your concerns (i.e. excluding configuration_view tool).

After thinking on this, maybe instead of adding a new profile that are mostly a set of static rules per each requirement. Maybe we can provide a custom profile that is fully up to the passed configuration file.

• included tools list
• namespace (default all)
• denied resources

@manusa WDYT?

[manusa]

We need to think about it.

It might be interesting to deal with all this in the scope of configuration files #131 + #137

If we check the GitHub MCP server, they introduced the concept of Dynamic tools (implementation) which is very similar to some of the features we want to tackle with profiles and configuration file.

My initial idea would be to create a set of well-defined tool groups for example:

• resources_readonly
• resources_destructive
• pods_readonly
• pods_destructive
• helm_readonly
• ...

The StaticConfig can then have a field toolSets which defines the tools available.
In addition, and in scope of #137, every other configuration flag should be settable via the config file too. ---> StaticConfig is the single source of truth for the MCP Server configuration+behavior.

Finally, continuing on #134, we can provide a set of predefined profiles with defaults (full, full-safe) for all values.

Still (see #137), some cmd flags are preserved for one-off overrides.

Config inheritance/extension should also be taken into account. i.e. a user wants to have the full behavior, but just limit the namespace.

[ardaguclu]

@N0YU0 allow/deny tool list makes sense. However, after thinking on this, I'm not sure I fully understand the namespace part.

Namespace is dynamic and changing based on each user. So that statically defining namespace in the config file of MCP Server will limit the entire MCP Server to a set of namespaces. Is this similar to what you proposed?.

[N0YU0]

@ardaguclu The namespace flag that I proposed was more so that you could define the scoped namespace that the mcp server could access.
I'm not sure if this would be a good addition to the configuration file, but as a cli flag it would help me immensely.
I use the mcp server in stdio mode every time a request is received on my server. For security purposes I would like to limit the mcp server that is running per request with the namespace given in the request (instead of trying to detect prompt injection of another namespace in the request body). I'm not sure if there is a better way to limit the call to the mcp for a specific namespace.

[ardaguclu]

What about non-namespaced resources?

[N0YU0]

I think ignoring it with cluster scoped resources, like the behavior of kubectl with --namespace flag with cluster scoped resources (e.g. kubectl get --namespace foo nodes) would be fine.

[ardaguclu]

@manusa so we don't need namespace based restriction? or we'll handle it in a different issue?.

[manusa]

@manusa so we don't need namespace based restriction? or we'll handle it in a different issue?.

Sorry, I missed this comment.

Do we still want/need to provide the namespace restriction?

[ardaguclu]

@manusa so we don't need namespace based restriction? or we'll handle it in a different issue?.

Sorry, I missed this comment.

Do we still want/need to provide the namespace restriction?

In my opinion, namespace restriction can be achieved by relying on RBAC rules in the cluster. If cluster admin correctly restricts access of the users to other namespaces, API server will automatically reject the requests already. We don't need to add such restriction in MCP Server.

[manusa]

In my opinion, namespace restriction can be achieved by relying on RBAC rules in the cluster. If cluster admin correctly restricts access of the users to other namespaces, API server will automatically reject the requests already. We don't need to add such restriction in MCP Server.

👍 This is precisely how I see it.
By adding client-side restrictions we're essentially duplicating the logic of RBAC and other Kubernetes components (with the maintenance burden this implies).

Once we have the entire OAuth flow working, we should document some of the common scenarios and how to achieve them.