Kubernetes publisher: cross-resource secret references generate broken Helm value paths

[mitchdenny]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When the Kubernetes publisher generates Helm charts and a project resource (e.g. webfrontend) references a secret owned by another resource (e.g. Redis cache password), the generated Helm template references a value path that does not exist in values.yaml, causing helm install to fail with a nil pointer error.

Error:

Error: INSTALLATION FAILED: template: aksredis-apphost/templates/webfrontend/secrets.yaml:11:67:
executing "aksredis-apphost/templates/webfrontend/secrets.yaml"
at <.Values.secrets.webfrontend.cache_password>: nil pointer evaluating interface {}.cache_password

Root Cause

The issue is in AllocateParameter() (KubernetesResource.cs:503). When processing webfrontend's connection string to Redis, it encounters the Redis password ParameterResource. The method creates a Helm expression using TargetResource (the consuming resource — webfrontend) instead of the owning resource (cache):

{{ .Values.secrets.webfrontend.cache_password }}   ← generated (WRONG)
{{ .Values.secrets.cache.REDIS_PASSWORD }}          ← where the value actually lives

The full flow:

1. Redis (cache) is processed → password stored in values.yaml as secrets.cache.REDIS_PASSWORD: ""
2. Webfrontend processes its Redis connection string → AllocateParameter(param, TargetResource) where TargetResource = webfrontend
3. Expression {{ .Values.secrets.webfrontend.cache_password }} gets embedded in the connection string via string.Format
4. ProcessEnvironmentStringValue() stores the connection string (with embedded expression) in webfrontend's secrets template
5. AddValuesToHelmSectionAsync() skips values where ValueContainsHelmExpression == true — so no secrets.webfrontend section is created in values.yaml
6. Helm evaluates {{ .Values.secrets.webfrontend.cache_password }} → secrets.webfrontend is nil → nil pointer error

Impact

This affects any Aspire app that uses container resources with secrets (e.g. Redis with password) and publishes to Kubernetes. The starter template with Redis enabled (aspire new → Yes for Redis) fails to deploy out of the box.

Reproduction

aspire new --name TestApp   # Select "Yes" for Redis
cd TestApp.AppHost
# Add Aspire.Hosting.Kubernetes package
aspire publish --publisher kubernetes --output-path ../charts
helm install test ../charts   # Fails with nil pointer error

Suggested Fix

AllocateParameter should reference the secret from the owning resource's namespace rather than re-namespacing it under the consuming resource. When a ParameterResource is encountered during cross-resource reference processing, the generated Helm expression should point to where the value actually exists in values.yaml.

Workaround

Provide the missing value manually via --set:

helm install test ../charts --set secrets.webfrontend.cache_password=""

Note: PR #14351 (AKS E2E deployment tests) includes this workaround in AksStarterWithRedisDeploymentTests.cs. When this issue is fixed, that workaround should be removed.

Expected Behavior

The webfrontend Helm template should reference {{ .Values.secrets.cache.REDIS_PASSWORD }} (or equivalent path where the value exists in values.yaml) instead of creating a broken reference under the consuming resource's namespace.

.NET Version info

dotnet --version: 10.0.x
aspire --version: 13.x

Anything else?

Related issues:

• (code provided) Minimal k8s aspire application generates invalid YAML assets: duplicate ports, invalid values, etc. #14029 — reports the duplicate ports issue for the same K8s publisher (fixed in PR Add AKS starter deployment E2E test #14351)
• Full support for Kubernetes Deployment #830 — general K8s deployment support tracking

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• aspire publish produces invalid helm configuration for database secrets #10994