Skip to content

fix(nvca): inject transport trust into Helm LLM utility pods #606

Description

@mikeyrcamp

Describe the bug

When workload.transportTLS.trustMode: bundle is configured, the NVCA
MiniService reconciliation path does not inject the transport CA bundle into
the Pylon container for Helm-based LLM functions.

Helm LLM translation places the Pylon llm-worker container in the generated
utils pod. MiniService reconciliation separates that pod from the translated
infrastructure objects, applies transport trust only to the ReVal-rendered
workloadObjs, and appends the utils pod afterward.

As a result, the real Helm LLM Pylon container does not receive:

  • The transport trust ConfigMap volume.
  • The merged-certificate emptyDir volume.
  • The trust-bundle installer init container.
  • The merged certificate mount.
  • STARGATE_TLS_CERT_PATH.

With QUIC insecure mode disabled and Stargate using a private CA, the worker
cannot authenticate the Stargate certificate or establish its reverse QUIC
tunnel. The connection fails closed; there is no insecure fallback.

Relevant code paths:

  • src/libraries/go/lib/pkg/icms-translate/translate/function/translate_helm.go
  • src/compute-plane-services/nvca/internal/miniservice/reconcile.go
  • src/compute-plane-services/nvca/internal/miniservice/transport_tls.go

Steps or code to reproduce bug

  1. Configure NVCA with bundle transport trust and
    stargateQUICInsecure: false.
  2. Create a Helm-based LLM function through the normal MiniService lifecycle.
  3. Inspect the generated utils pod containing llm-worker.
  4. Observe that the pod lacks the transport trust volumes and installer init
    container.
  5. Observe that llm-worker lacks the merged certificate mount and
    STARGATE_TLS_CERT_PATH.

The existing helper-level test does not reproduce the lifecycle. It constructs
an artificial Pod containing llm-worker and passes that Pod directly to
prepareTransportTLSForWorkloads, bypassing the separation and later append of
the real Helm utils pod.

Expected behavior

Before creating the Helm utils pod, NVCA should apply the configured
transport trust mutation to it when it contains llm-worker.

Only the llm-worker container should receive the merged certificate mount and
STARGATE_TLS_CERT_PATH. The credential manager and customer workload
containers must remain unchanged.

Add an integration-level regression test that starts with a Helm LLM launch
specification, runs the MiniService reconciliation path, and verifies the
created utils pod contains the expected ConfigMap volume,
merged-certificate volume, installer init container, mount, and environment
variable.

Existing container-function behavior and fail-closed validation for malformed
bundles or fingerprint mismatches must remain unchanged.

Additional context

This is the Helm-specific lifecycle gap in the broader transport-trust work
tracked by #50.

Metadata

Metadata

Assignees

Labels

needs-triageIssue or PR awaiting maintainer triage

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions