Introduce require-oauth flag
When this flag is enabled, authorization middleware will be turned on.
When this flag is enabled, Derived which is generated based on the client
token will not be used.
---
Wire Authorization middleware to http mux
This commit adds authorization middleware. Additionally, this commit
rejects the requests if the bearer token is absent in Authorization
header of the request.
---
Add offline token validation for expiration and audience
Per Model Context Protocol specification, MCP Servers must check the
audience field of the token to ensure that they are generated specifically
for them.
This commits parses the JWT token and asserts that audience is correct
and token is not expired.
---
Add online token verification via TokenReview request to API Server
This commit sends online token verification by sending request to
TokenReview endpoint of API Server with the token and expected audience.
If API Server returns the status as authenticated, that means this token
can be used to generate a new ad hoc token for MCP Server.
If API Server returns the status as not authenticated, that means this token
is invalid and MCP Server returns 401 to force the client to initiate OAuth flow.
---
Serve oauth protected resource metadata endpoint
---
Introduce server-url to be represented in protected resource metadata
---
Add error return type in Derived function
---
Return error if error occurs in Derived, when require-oauth
---
Add test cases for authorization-url and server-url
---
Wire server-url to audience, if it is set
---
Remove redundant ssebaseurl parameter from http
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>
