OAuth 2.0: 401 - Unauthorized header

[manusa]

Description

To properly implement OAuth 2.0 workflows, the HTTP server implemented in scope of #135 - #153, must return a 401 - Unauthorized status in case the client is not authenticated.

As agreed internally, the authorization workflow will be active for HTTP and SSE provided that the server is started with --require-auth (or similar) config flag (to be included in flags + StaticConfig).

In case auth is required, the middleware context function will check for an authorization header.
If the header is not present, a 401 status code is returned forcing the client to start the OAuth flow (see attached sequence diagram).
For the custom kubernetes-authorization header, no checks are performed, the header value is simply propagated to the Kube-API.

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• Relates to OAuth 2.0: Protected Resource Metadata #160

[r0b0t2k]

Hi, I am a new user to MCPs, and I recently successfully setup this MCP in my local vscode environment, as well as a remote MCP in a kubernetes environment, but that is when I realized there is nothing stopping someone on my network from using the endpoint I exposed to use the MCP server with its permissions to access resources in the cluster.

So I came to the issues tab to see if there was anything related to authentication. Is it safe to assume the post you have made here means there is no auth mechanism yet for access to the MCP server?

[r0b0t2k]

Hi, I am a new user to MCPs, and I recently successfully setup this MCP in my local vscode environment, as well as a remote MCP in a kubernetes environment, but that is when I realized there is nothing stopping someone on my network from using the endpoint I exposed to use the MCP server with its permissions to access resources in the cluster.

So I came to the issues tab to see if there was anything related to authentication. Is it safe to assume the post you have made here means there is no auth mechanism yet for access to the MCP server?

So this might be funny to you all not sure, but I used copilot to review the code of this MCP server to understand how to Auth to it, if this was in the docs I apologize I never saw it. But I learned the following and it seems to work well for a remote MCP server.

    "mcp": {
        
        "servers": {
            "kubernetes": {
            "url": "https://secure-mcp-server-kubernetes.apps.myopenshift.mydomain.net/mcp",
            "headers": {
                "kubernetes-authorization": "Bearer <mytoken>"            
               }
            }
        }
    }
}

So just by adding my token I get the permissions to the mcp server that I would have normally. I will keep reading in case I am missing something else.

[manusa]

I realized there is nothing stopping someone on my network from using the endpoint I exposed to use the MCP server with its permissions to access resources in the cluster.

Yes, there's nothing (officially) built into the server that's preventing anyone to access you server in case it's exposed publicly.

In the repo, there are no Helm charts, documented Kubernetes manifests, and so on, to prevent people from accidentally exposing the MCP server (unless they know exactly what they are doing).

This doesn't mean that it can't be done, but you should definitely use some means of protection.

There are multiple options:

• reverse-proxy or gateway with auth
• MCP gateway that provides auth
• Any other line of defense you can think of

So this might be funny to you all not sure, but I used copilot to review the code of this MCP server to understand how to Auth to it, if this was in the docs I apologize I never saw it.

No need to apologize, this is not documented yet because it's (was) an experimental feature that has derived into the standard OAuth implementation details.

What you really want in this case, is to ensure that the config the MCP Server is running on contains only the minimum required fields (host, TLS certs if necessary, etc.), but with none of the auth fields.

Then, your client can pass the kubernetes-authorization header with a bearer token that was issued to the Kubernetes user.

This will ensure that unless the header is present and the user is authorized, there's no way the MCP server can perform actions on the configured cluster.

[r0b0t2k]

First of all, thank you for your well thought out reply I can imagine you are very busy.

In the repo, there are no Helm charts, documented Kubernetes manifests, and so on, to prevent people from accidentally exposing the MCP server (unless they know exactly what they are doing).

Yes, so far I have learned how to deploy it in OpenShift in my home_lab, once I learned how to pass auth to it via the
kubernetes-authorization header that is when I realized the container, should receive a serviceaccount with a role that essentially has no access(no rules) this allows the MCP server to be exposed, but does not give anyone access unless they pass a valid Header.

This doesn't mean that it can't be done, but you should definitely use some means of protection.

There are multiple options:

• reverse-proxy or gateway with auth
• MCP gateway that provides auth
• Any other line of defense you can think of

Unfortunately I have limited experience doing this type of thing, but I am eager to learn, I will see what I can figure out on my own based on your recommendation.

What you really want in this case, is to ensure that the config the MCP Server is running on contains only the minimum required fields (host, TLS certs if necessary, etc.), but with none of the auth fields.

Then, your client can pass the kubernetes-authorization header with a bearer token that was issued to the Kubernetes user.

This will ensure that unless the header is present and the user is authorized, there's no way the MCP server can perform actions on the configured cluster.

I have essentially tested this and it works well, again issuing a ServiceAccount to the container that has no access to anything. The MCP server picks that account up on its own, I assume because it searches for the .kube/config. I have used copilot to send prompts to the server without a header, and it basically confirms that it is missing permissions to do anything.

Oh one last thing, not a big deal, but via copilot it cannot issue the starting of builds in OpenShift, I assume this is because BuildConfigs are an OpenShift construct and not part of vanilla kubernetes. Are there any plans to eventually accommodate OpenShift specific tasks with this kubernetes-mcp-server? No biggie if not, I just wanted to get a little insight if there is any to be shared.