- Refactor tests to use testify (more clarity+composability for complex tests)
- Tests for default toolsets
- Tests for configured, granular toolsets
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Users can now enable or disable different toolsets either by providing
a command-line flag or by setting the toolsets array field in the TOML
configuration.
Downstream Kubernetes API developers can declare toolsets for their
APIs by creating a new nested package in pkg/toolsets and registering
it in pkg/mcp/modules.go
Signed-off-by: Marc Nuri <marc@marcnuri.com>
As a prior step to providing support for toolsets
this change repurposes the current work in profiles
which partially aligns with the toolsets expected features
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Introduce allow/deny tool functionality in toml config
---
Remove duplicate fields that already defined in staticConfig
---
Add unit tests to verify tool valid check
---
Wire staticConfig to fix unit tests
---
Rename to enabled/disabled instead of allowed/denied
A new configuration options is available: `--list-output`
There are two modes available:
- `yaml`: current default (will be changed in subsequent PR), which returns a multi-document YAML
- `table`: returns a plain-text table as created by the kube-api server when requested with
`Accept: application/json;as=Table;v=v1;g=meta.k8s.io`
Additional logic has been added to the table format to include the apiVersion and kind.
This is not returned by the server, kubectl doesn't include this either.
However, this is extremely handy for the LLM when using the generic resource tools.
feat(auth): Authorize user from custom SSE header
PoC to show how we can propagate an Authorization Bearer token
from the MCP client up to the Kubernetes API by passing a custom
header (Kubernetes-Authorization-Bearer-Token).
A new Derived client is necessary for each request due to the incompleteness
of some of the client-go clients.
This might add some overhead for each prompt.
Ideally, the issue with the discoveryclient and others should be fixed to
allow reading the authorization header from the request context.
To use the feature, the MCP Server still needs to be started with a basic
configuration (either provided InCluster by a service account or locally by
a .kube/config file) so that it's able to infer the server settings.
---
test(auth): added tests to verify header propagation
---
refactor(auth): minor improvements for derived client
This PR introduces the ability to filter Kubernetes resources by label using a labelSelector parameter for the following tools:
* pods_list
* pods_list_in_namespace
* resources_list
This enhancement allows users to retrieve a more specific set of resources based on their labels, improving the flexibility and utility of these tools.
The labelSelector parameter accepts standard Kubernetes label selector syntax, such as app=myapp,env=prod or app in (myapp,yourapp).
Signed-off-by: Eran Cohen <eranco@redhat.com>
Watch kube config files for changes.
Automatically reload kubernetes client and list of tools.
Useful for logins or context changes after an MCP session has started.