Kustomize 5.8.0 no longer add namespaces to resources in helm charts without explicit namespace

[codestation]

What happened?

Before kustomize 5.8.0 if i declare the namespace in the /namespace of the kustomization.yaml file it will add a namespace to all the resources without an explicit namespace.

After 5.8.0 it won't add the namespace, breaking several 3rd party charts where the resources doesn't have an explicit namespace: {{ .Release.Namespace }} template.

For example i can no longer install the mariadb-operator chart in argocd after the kustomize update because the resources no longer have a namespace.

As a workaround for this specific chart i am using the following:

patches:
  - target:
      kind: (ConfigMap|ServiceAccount|Deployment|ServiceMonitor|Role|RoleBinding|Service)
    patch: |-
      - op: add
        path: /metadata/namespace
        value: mariadb-system

But this can break anytime the chart or values.yaml is updated.

What did you expect to happen?

The resources must have a namespace like in previous versions.

How can we reproduce it (as minimally and precisely as possible)?

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: mariadb-system
helmCharts:
  - name: mariadb-operator
    repo: https://helm.mariadb.com/mariadb-operator
    version: 25.10.4
    releaseName: mariadb-operator
    namespace: mariadb-system

Expected output

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: mariadb-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: mariadb-operator
    app.kubernetes.io/version: 25.10.4
    helm.sh/chart: mariadb-operator-25.10.4
  name: mariadb-operator
  namespace: mariadb-system
spec:
...

Actual output

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: mariadb-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: mariadb-operator
    app.kubernetes.io/version: 25.10.4
    helm.sh/chart: mariadb-operator-25.10.4
  name: mariadb-operator
spec:
...

Kustomize version

5.8.0

Operating system

Linux

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kenlasko]

I see the same behaviour in 5.8.0. Found this after upgrading ArgoCD to 3.3.0, which includes Kustomize 5.8.0. Older versions use <5.8.0

[CreMindES]

I can also confirm this.
Even if we add a patch to the base, that does add the namespace to every item that is missing it in the helm chart, kustomize no longer updates it in the overlays. This almost broke a few things on our side.

[Skaronator]

The underlying issue is that helm template does not inject the metadata.namespace field, unlike helm install. There are several related issues discussing this behavior:

• --namespace is ignored by "helm template" helm/helm#10737
• helm template --namespace should set the 'metadata.namespace' field on created resources helm/helm#3553

Previously, Kustomize always applied the NamespaceTransformer to the output of helm template. This caused problems for Helm charts that intentionally create resources across multiple namespaces.

A good example is the cert-manager Helm chart. It creates a RoleBinding in the kube-system namespace for leader election (see: https://github.com/cert-manager/cert-manager/blob/0a0a7ea5ad4055c781444e353e2b26bccbb70df8/deploy/charts/cert-manager/templates/rbac.yaml#L30). The Kustomize NamespaceTransformer was overly aggressive and rewrote the namespace, making it impossible to install the chart as intended.

This is why I created the Issue #5566, which was upvoted to the 5th highest position.

In my opinion, being explicit in the Helm chart and always setting namespace: {{ .Release.Namespace }} in the metadata block is the most straightforward solution. However, considering the number of related issues and different use cases, it's probably not the best solution for everyone.

I'll look into this further, but I have the feeling that there is no one-size-fits-all solution to this issue.

[xdrus]

Unfortunately, the new feature breaks a few legit use cases that worked fine before:

1. I can't now explicitly set namespaces for 3rd party helm charts that do not set namespace in templates. For example: https://github.com/launchdarkly/ld-relay-helm/blob/main/templates/deployment.yaml#L3-L6
2. I can't now override namespace in overlays. Common use case is that I have base with "default" namespace set, but for various reasons (i.e. testing) I override namespace in overlay. Now it doesn't work.

Just an example for 2 use-case:

• base:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmCharts:
- name: nack
  releaseName: nack
  namespace: nats
  version:  0.28.1
  includeCRDs: true
  repo: https://nats-io.github.io/k8s/helm/charts/

overlay using remote:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: random

resources:
  - https://github.com/<my-repo>//base/nack-nats?ref=test-kustomize

Expected output of kustomize build --enable-helm | grep "namespace:" | sort -u:

  namespace: random

Actual output:

  namespace: nats

[rguhr]

The underlying issue is that helm template does not inject the metadata.namespace field, unlike helm install. There are several related issues discussing this behavior:

• --namespace is ignored by "helm template" helm/helm#10737
• helm template --namespace should set the 'metadata.namespace' field on created resources helm/helm#3553

Previously, Kustomize always applied the NamespaceTransformer to the output of helm template. This caused problems for Helm charts that intentionally create resources across multiple namespaces.

A good example is the cert-manager Helm chart. It creates a RoleBinding in the kube-system namespace for leader election (see: https://github.com/cert-manager/cert-manager/blob/0a0a7ea5ad4055c781444e353e2b26bccbb70df8/deploy/charts/cert-manager/templates/rbac.yaml#L30). The Kustomize NamespaceTransformer was overly aggressive and rewrote the namespace, making it impossible to install the chart as intended.

This is why I created the Issue #5566, which was upvoted to the 5th highest position.

In my opinion, being explicit in the Helm chart and always setting namespace: {{ .Release.Namespace }} in the metadata block is the most straightforward solution. However, considering the number of related issues and different use cases, it's probably not the best solution for everyone.

I'll look into this further, but I have the feeling that there is no one-size-fits-all solution to this issue.

@Skaronator Helm will not change this behavior for the template subcommand, so we need to find a solution on the Kustomize side.

At the moment, the namespace: field in the HelmChart builtin is only passed as an argument to the helm template command. It is not reflected in the rendered manifests themselves.

Without accessing a live Kubernetes cluster, there is no reliable way to determine scope dynamically. The only deterministic approach I can think of would be:

Inject the HelmChart namespace into all rendered resources that do not already declare metadata.namespace.

Cluster-scoped resources should not be an issue here, since the Kubernetes API ignores the namespace field for them. This wouldpreserve explicitly defined namespaces inside charts and therefore not break multi-namespace charts like cert-manager.

This might not be the most aesthetically clean solution, but it would be functional and predictable.

Otherwise, the HelmChart builtin is hard to use reliably in practice. Users would first need to audit every upstream chart to verify that {{ .Release.Namespace }} is consistently set in all templates. If it isn’t, they would have to fork the chart or maintain patches and then re-validate this on every upstream update.

That creates a significant maintenance burden and defeats much of the purpose of consuming upstream Helm charts unmodified.