[FEATURE] Support optional modelConfig reference in BYO Agent CRD (spec.type: BYO) for secure, centralized model credential governance #1367
Description
📋 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
Optional modelConfig support for BYO Agent CRDs (spec.type: BYO) to centralize model/provider/API-key governance.
❓ Problem Statement / Motivation
Today, BYO agents appear to require custom env/secret wiring per image for model/provider credentials.
This creates several problems:
- repeated secret/config logic across BYO agents
- inconsistent security and governance patterns between teams
- higher risk of misconfiguration and credential sprawl
- duplication of governance features that already exist in kagent ModelConfig flows (for non-BYO paths)
Who benefits:
- teams running multiple BYO agents
- security/compliance-focused operators
- platform teams that want one standardized credential governance model
Why needed:
BYO should not force users to invent separate credential governance from the rest of kagent.
💡 Proposed Solution
Add optional modelConfig reference support for BYO agents. Example shape (illustrative):
spec:
type: BYO
modelConfigRef:
name: default-model-config
(or under spec.byo, depending on preferred CRD structure)
Expected behavior when set:
Controller resolves provider/model/auth from referenced ModelConfig
Controller injects standardized runtime config into BYO workload (env/projection/etc.)
BYO workloads can consume config without bespoke secret plumbing
Changes/rotation at ModelConfig level propagate consistently
Backward compatibility:
If modelConfigRef is omitted, existing BYO behavior remains unchanged.
Potential optional enhancements:
- policy to allow/deny BYO model override
- expose non-secret metadata (MODEL_PROVIDER, MODEL_NAME) in a standard way
- document exact BYO runtime contract for injected config
🔄 Alternatives Considered
- Keep current approach (manual env + secret wiring in each BYO image)
- works, but causes duplication/drift and weaker governance consistency
- Build custom in-app “ModelConfig bridge” logic in every BYO implementation
- possible, but redundant and error-prone across languages/teams
🎯 Affected Service(s)
Controller Service
📚 Additional Context
Motivation is to improve parity between declarative and BYO operational models, especially for secure key management and centralized governance.
This would reduce custom boilerplate and improve security posture for BYO adoption.
🙋 Are you willing to contribute?
- I am willing to submit a PR for this feature