Conversation
ppatierno
left a comment
There was a problem hiding this comment.
I like the idea. This MCP server has been on my radar for too long but time is always not enough and I am happy to see something "official" starting here. I left several comments ... sorry! But I would be really happy to help if needed :-)
MikeEdgar
left a comment
There was a problem hiding this comment.
My main question is around scope of the project. If it is ever only to be Strimzi-focused, why not propose having it hosted in the Strimzi organization?
I'm happy to get any feedback |
tomncooper
left a comment
There was a problem hiding this comment.
I think this is a good idea and solid start but I have a few concerns, most of which are commented directly on the doc. I'll summarise my main points below:
- I agree with other commenters that a StreamsHub MCP mono-repo with this as the first sub-module is probably the best way to go. If we create a Kafka, Kroxy, Console etc MCPs there will undoubtably be a lot of shared logic.
- I think it would be a good idea to step back and think about what questions a DevOps users would want to ask an LLM about Strimzi. From that list you can then figure out what tools we would need to fulfil them.
- As well as MCP Tools, I think it would be worth exploring what MCP Resources and MCP Prompts could offer. I actually think MCP resource change subscriptions could be really intesting for incident monitoring. MCP Prompt templates could allow us to guide the LLMs on what aspects of the Stimzi deployment to look at when diagnosing issues etc. However, if you don't think they offer anything useful then you should add a section on why.
- If you do have a list of typical user questions you could see how an LLM agent with
kubctlgets on currently. What issues does it hit, where could an MCP smooth the process. This is where I think MCP Resources and MCP prompts could really help. - I think we need to target the smallest possible set of permissions not the Strimzi SA.
- I think we need to cover how AuthZ will work. What if there is a PII Kafka cluster or namespace and only certain users should be able to see details about it.
- For the MCP tool outputs I have some specific concerns around security and limiting context overload/pollution.
- You are going to need to have a way to validate/sanitize input. Prompt injection protection will need to be considered. Also JSON Schemas will be needed for the tool inputs.
|
@ppatierno @tomncooper @Frawless @MikeEdgar |
@tomncooper I think we could use integration for external OIDC services and get identity verification via it. Fabric8 then could use user impersonation with data from OIDC (user's name an groups). Kube admin will configure RBAC access to a specific user/groups and MCP will have basically same access as all Kube API calls will uses user's impersonation data. Keycloak for example also allows offline access tokens or PATs that could be used to long-live tokens for AI assistants, but I am not sure how it will work if we will use GitHub OIDC for example, guess there will be some similar way? Anyway I will dig it more into it and maybe we could discuss it on slack or on a call to avoid to much pollution here as I expect it will need quite a long discussion. Maybe there we could also learn form Console folks how they do Authz and if there will be something we can do in similar way in our use case. |
Frawless
left a comment
There was a problem hiding this comment.
Just few nits, otherwise it looks good to me with all know limitations mentioned in the proposal. +1 from me.
tomncooper
left a comment
There was a problem hiding this comment.
Thanks for addressing many of my previous concerns, this is a much more comprehensive proposal. I had a few more comments.
Signed-off-by: David Kornel <kornys@outlook.com>
tomncooper
left a comment
There was a problem hiding this comment.
Thanks for addressing my previous comments, I think this is nearly there, I just had a few questions around the MCP Prompt templates and permissions granted to the MCP Server Service Account.
Signed-off-by: David Kornel <kornys@outlook.com>
No description provided.