[FEATURE] Make ModelConfig shareable

[davidkarlsen]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

Add support for referencing a ModelConfig in another namespace

❓ Problem Statement / Motivation

My use-case is to have low-effort declarative agents in various namespaces, which refer to a common ModelConfig provided in my kagent system namespace. Then it is easier for an user to define an agent w/o having to dig up a model and secrets for it.

💡 Proposed Solution

Similar to how tools can be shared, add support for namespace references to share to.

🔄 Alternatives Considered

v1alpha1 supported this afaik, but it seems like a bad idea to rely on old api versions

🎯 Affected Service(s)

None

📚 Additional Context

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature

[mesutoezdil]

Looks cool. The codebase already has patterns for this.

TypedReference in agent_types.go has an optional Namespace field.
Agents already use it for cross-namespace tool references.
The modelConfig field in AgentSpec could use the same type instead of a plain string.

AllowedNamespaces is already on Agent to control who can reference it.
The same field could be added to ModelConfig.

The api key secret stays in the same ns as the ModelConfig, so no extra rbac needed.

[EItanya]

I'm actually realizing that this will require some rather large changes. Right now we directly mount secrets to avoid copying/writing the secret materials. However, if secret materials are cross namespace we will need to start writing them to the config rather than mounting them separately.

@iplay88keys how does this work for the RemoteMCPServer certs which were just added?

[iplay88keys]

RemoteMCPServer CA secrets follow the same pattern ModelConfig uses: the secret is mounted by bare name and resolved in the agent pod's namespace. But the controller validates and hashes that secret in the RemoteMCPServer's namespace. AllowedNamespaces only governs who can reference the RemoteMCPServer object.

I think that highlights a bug in the RemoteMCPServer logic, though. The RemoteMCPServer object can be referenced cross-namespace, but when CA certs try to be mounted, they will either fail or the incorrect certs will be mounted (if there's a matching secret name in the agent's namespace). I think we should disallow cross-namespace RemoteMCPServer attachment as a result. It was different when there were no CA certs, but I don't think we should be copying secret materials across namespaces at this point.