[FEATURE] Helm chart providers.<name> values do not expose ModelConfig spec.tls — TLS config unreachable for chart-generated default ModelConfig

[davidkarlsen]

[FEATURE] Helm chart providers.<name> values do not expose ModelConfig spec.tls — TLS config unreachable for chart-generated default ModelConfig

Summary

The kagent Helm chart (v0.9.6) generates a default ModelConfig from .Values.providers.<default> but does not render spec.tls onto it, and provides no toggle to skip auto-generation. The kagent.dev/v1alpha2 ModelConfig CRD fully supports a spec.tls block (disableVerify, caCertSecretRef, caCertSecretKey, disableSystemCAs), but these fields are unreachable via chart values — any tls: key placed under providers.openAI: (or any provider) is silently ignored.

---

Chart version

0.9.6 — OCI: oci://ghcr.io/kagent-dev/kagent/helm/kagent --version 0.9.6

---

What happened

The template templates/modelconfig.yaml renders only these spec fields:

# templates/modelconfig.yaml (chart v0.9.6) — full spec section
spec:
  {{- with $model }}
  provider: {{ .provider | quote }}
  model: {{ .model | quote }}
  {{- if $model.apiKeySecretRef }}
  apiKeySecret: {{.apiKeySecretRef}}
  {{- end }}
  {{- if $model.apiKeySecretKey }}
  apiKeySecretKey: {{.apiKeySecretKey}}
  {{- end }}
  {{- if hasKey $model "defaultHeaders" }}
  defaultHeaders:
    {{- toYaml $model.defaultHeaders | nindent 4 }}
  {{- end }}
  {{- if $model.config }}
  {{ $dot.Values.providers.default }}:
  {{- toYaml $model.config | nindent 4 }}
  {{- end }}
  {{- end }}

There is no tls: block in the template. Running helm show values oci://ghcr.io/kagent-dev/kagent/helm/kagent --version 0.9.6 confirms no tls or disableVerify key appears anywhere under providers.* in the default schema.

Additionally, the template renders unconditionally — there is no guard such as {{- if .Values.providers.createDefaultModelConfig }}. A user cannot opt out of the auto-generated default-model-config and supply a hand-authored one of the same name without an Argo CD / kubectl ownership conflict.

---

What I expected

All fields documented in the ModelConfig CRD should be reachable via providers.<name>.* Helm values. Placing tls.disableVerify: true under a provider block should produce spec.tls.disableVerify: true on the generated ModelConfig.

---

CRD support evidence

The kagent.dev/v1alpha2 ModelConfig CRD exposes a full spec.tls block (official API reference):

Field	Type	Default	Description
spec.tls.disableVerify	boolean	false	Disables SSL certificate verification entirely
spec.tls.caCertSecretRef	string	—	Reference to a Secret containing a PEM CA cert (same namespace)
spec.tls.caCertSecretKey	string	—	Key within that Secret
spec.tls.disableSystemCAs	boolean	false	When true, only the custom CA from caCertSecretRef is trusted

A manually-authored standalone ModelConfig with spec.tls works correctly. The gap is exclusively that the chart does not render this path for the auto-generated default.

---

Minimal repro

# values.yaml — the tls key is silently ignored and never reaches spec.tls
providers:
  default: openAI
  openAI:
    provider: OpenAI
    model: gpt-4.1-mini
    apiKeySecretRef: kagent-openai
    apiKeySecretKey: OPENAI_API_KEY
    tls:
      disableVerify: true   # silently dropped; never rendered into spec.tls

The generated ModelConfig contains no tls: field at all.

Workaround (functional but awkward): Author a separate standalone ModelConfig with spec.tls.disableVerify: true and point Agents to it explicitly. You cannot use the chart-generated default-model-config name without a resource ownership conflict since the chart always creates it unconditionally.

---

Real-world impact

In enterprise environments behind a TLS-intercepting corporate proxy (MITM — e.g. CheckPoint/CloudGuard), the agent runtime (Python httpx-based OpenAI/litellm client) cannot verify the intercepted certificate chain.

Observed failure: the MITM CA is rejected by Python's stricter verifier with CERTIFICATE_VERIFY_FAILED: Missing Authority Key Identifier while curl tolerates it. The spec.tls.disableVerify: true field on a standalone ModelConfig resolves this, but it cannot be reached via the chart for the auto-generated default ModelConfig.

This affects users deploying kagent in:

• Corporate networks with MITM / SSL-inspection proxies
• Air-gapped or private environments with internal CAs not in Python's certifi bundle
• Any context where the Python httpx client cannot validate the LLM provider certificate against system roots

---

Feature request

1. Expose spec.tls passthrough in chart values — add a tls: block under each provider's values schema and render it into the generated ModelConfig.

Proposed values addition (applies to all providers):

providers:
  openAI:
    provider: OpenAI
    model: gpt-4.1-mini
    apiKeySecretRef: kagent-openai
    apiKeySecretKey: OPENAI_API_KEY
    tls:               # NEW — maps directly to spec.tls
      disableVerify: false
      caCertSecretRef: ""
      caCertSecretKey: ""
      disableSystemCAs: false

Minimal template addition needed in templates/modelconfig.yaml:

  {{- if $model.tls }}
  tls:
    {{- toYaml $model.tls | nindent 4 }}
  {{- end }}

2. Add a toggle to skip auto-generation of the default ModelConfig — e.g. providers.defaultModelConfig.create: true (default true). This lets users supply their own ModelConfig of the same name with any spec fields they need, without a resource ownership conflict.

---

Related / prior issues

• #775 Add custom CAs for LLM calls — added spec.tls to the CRD (making this request feasible); Helm chart values were not updated
• #485 SSL Certificate verification failure with self-signed certificates — original SSL bug that motivated CRD support; chart gap remained after the fix
• #1122 Support TLS configuration for Non-OpenAI LLM Providers — closed/not planned; addressed Python SDK parity across providers, not chart values
• #1123 Add support for global LLM TLS CA configuration — closed/not planned; proposed a global CA mechanism with no CRD proposal; this issue is narrower and directly actionable
• #867 Chart configurable providers not up to date — same class of chart-CRD gap (Gemini provider missing from chart values)

[davidkarlsen]

Related: #1992 — a distinct gap in the embedding code path (_embedding.py ignores ModelConfig.spec.tls). Same TLS-config-unreachable theme, different code location; fixing this chart issue won't fix that one.