📋 Prerequisites
📝 Feature Summary
Add Azure Foundry model provider/backend support
❓ Problem Statement / Motivation
Foundry provides a unified platform for deploying and consuming multiple model families on Azure. kagent users should be able to configure agents against foundry deployments directtly, using Azure-native endpoints and identity.
https://azure.microsoft.com/en-us/products/ai-foundry/models/
Supporting this feature allows users to use their existing Azure AI infrastructure, governance, and identity setup
💡 Proposed Solution
Add a dedicated AzureFoundry provider with:
- A new provider-specific
AzureFoundryConfig in ModelConfig
- Auth modes for:
- static API key
- Azure Workload Identity
- API key passthrough
- Provider-assisted Azure Workload Identity wiring when kagent owns the generated ServiceAccount:
- add
azure.workload.identity/use: "true" pod label
- add
azure.workload.identity/client-id ServiceAccount annotation
- optionally add
azure.workload.identity/tenant-id
- Standard Kubernetes
ConfigMap/Secret refs for endpoint/client ID/tenant ID values, so ASO (more details below) can export required values without kagent taking a hard dependency on ASO CRDs
- Foundry-specific runtime configuration names rather than reusing Azure OpenAI env vars
- Support for existing
spec.tls behavior
🔄 Alternatives Considered
Reuse or augment the AzureOpenAI provider. Foundry should be a first-class backend with its own config for a better user experience
🎯 Affected Service(s)
Multiple services / System-wide
📚 Additional Context
Azure Service Operator (ASO) (https://github.com/Azure/azure-service-operator) is a Kubernetes operator that manages Azure resources using Kubernetes custom resources. For this feature, ASO is relevant because users may provision Azure Foundry-related Azure resources from Kubernetes, such as Cognitive Services accounts, Foundry projects, model deployments, user-assigned managed identities, federated identity credentials, and role assignments.
The kagent integration should not depend directly on ASO CRDs. Instead, ASO can be one possible way to expose the values kagent needs through ordinary Kubernetes ConfigMap and Secret objects. For example:
- a Foundry/Cognitive Services endpoint exported to a
ConfigMap
- a user-assigned managed identity client ID exported to a
ConfigMap
- a tenant ID exported to a
ConfigMap
- an account API key exported to a
Secret
kagent would then consume those normal Kubernetes refs in ModelConfig, keeping the Azure Foundry backend usable with or without ASO while still supporting users who manage Azure infrastructure through Kubernetes.
🙋 Are you willing to contribute?
📋 Prerequisites
📝 Feature Summary
Add Azure Foundry model provider/backend support
❓ Problem Statement / Motivation
Foundry provides a unified platform for deploying and consuming multiple model families on Azure. kagent users should be able to configure agents against foundry deployments directtly, using Azure-native endpoints and identity.
https://azure.microsoft.com/en-us/products/ai-foundry/models/
Supporting this feature allows users to use their existing Azure AI infrastructure, governance, and identity setup
💡 Proposed Solution
Add a dedicated
AzureFoundryprovider with:AzureFoundryConfiginModelConfigazure.workload.identity/use: "true"pod labelazure.workload.identity/client-idServiceAccount annotationazure.workload.identity/tenant-idConfigMap/Secretrefs for endpoint/client ID/tenant ID values, so ASO (more details below) can export required values without kagent taking a hard dependency on ASO CRDsspec.tlsbehavior🔄 Alternatives Considered
Reuse or augment the AzureOpenAI provider. Foundry should be a first-class backend with its own config for a better user experience
🎯 Affected Service(s)
Multiple services / System-wide
📚 Additional Context
Azure Service Operator (ASO) (https://github.com/Azure/azure-service-operator) is a Kubernetes operator that manages Azure resources using Kubernetes custom resources. For this feature, ASO is relevant because users may provision Azure Foundry-related Azure resources from Kubernetes, such as Cognitive Services accounts, Foundry projects, model deployments, user-assigned managed identities, federated identity credentials, and role assignments.
The kagent integration should not depend directly on ASO CRDs. Instead, ASO can be one possible way to expose the values kagent needs through ordinary Kubernetes
ConfigMapandSecretobjects. For example:ConfigMapConfigMapConfigMapSecretkagent would then consume those normal Kubernetes refs in
ModelConfig, keeping the Azure Foundry backend usable with or without ASO while still supporting users who manage Azure infrastructure through Kubernetes.🙋 Are you willing to contribute?