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
- Configure NVCA with bundle transport trust and
stargateQUICInsecure: false.
- Create a Helm-based LLM function through the normal MiniService lifecycle.
- Inspect the generated
utils pod containing llm-worker.
- Observe that the pod lacks the transport trust volumes and installer init
container.
- 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.
Describe the bug
When
workload.transportTLS.trustMode: bundleis configured, the NVCAMiniService 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-workercontainer in the generatedutilspod. MiniService reconciliation separates that pod from the translatedinfrastructure objects, applies transport trust only to the ReVal-rendered
workloadObjs, and appends theutilspod afterward.As a result, the real Helm LLM Pylon container does not receive:
emptyDirvolume.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.gosrc/compute-plane-services/nvca/internal/miniservice/reconcile.gosrc/compute-plane-services/nvca/internal/miniservice/transport_tls.goSteps or code to reproduce bug
stargateQUICInsecure: false.utilspod containingllm-worker.container.
llm-workerlacks the merged certificate mount andSTARGATE_TLS_CERT_PATH.The existing helper-level test does not reproduce the lifecycle. It constructs
an artificial Pod containing
llm-workerand passes that Pod directly toprepareTransportTLSForWorkloads, bypassing the separation and later append ofthe real Helm
utilspod.Expected behavior
Before creating the Helm
utilspod, NVCA should apply the configuredtransport trust mutation to it when it contains
llm-worker.Only the
llm-workercontainer should receive the merged certificate mount andSTARGATE_TLS_CERT_PATH. The credential manager and customer workloadcontainers 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
utilspod 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.