Feature: Implement Delegated Auth and Token Exchange Patterns

[usize]

Problem

As of now, the agents and MCP servers deployed here rely on their local service accounts for Kubernetes API access.

This pattern is sufficient for prototyping, but needs to be improved for demonstration of best-practices.

In short, our MCP servers should accept Kubernetes API tokens and use them to act on behalf of the caller. The A2A bridge already has this capability.

Agents on the other hand, should exchange their workload identity as provided by SPIRE for an API token.

Proposed Solution

This can be achieved using:

[Spiffe Certificate] -> [KeyCloak JWT] -> [Pinniped K8s JWT]

Where Pinniped will return a token. The process could be further improved by introducing Authorino.

[Spiffe Certificate] -> [KeyCloak JWT] -> [Authorino] -> [Pinniped K8s JWT]

Since Authorino can handle the token exchange process transparently, swapping out the JWT in the auth header.

They key to achieving this will be setting up an integration with Pinniped Concierge, which allows for OIDC integration and issues K8s JWT tokens.

https://pinniped.dev/docs/howto/install-concierge/

Acceptance Criteria

Agents are capable of exchanging their workload identity for a KeyCloak JWT and passing it via request headers to an MCP server. En route, the KeyCloak JWT is intercepted and exchanged for a Kubernetes API JWT such that the MCP server may use it to make API calls on the Agent's behalf.

[webchang]

I'll follow up.

[usize]

Hi @webchang I built a prototype of this some time ago and kept running into a wall with Pinnipied. If you come up with a solution that would be really neat honestly.