kustomize: namespace not supported by helmCharts

Bumping again as this breaks our flow of specifying namespace in overlays completely.

The community position on some of these flaws are baffling.

I cannot inline edit multi-line string values for some of my YAML objects after flattening a helm chart, so I go towards the helmChart generator for an exception basis.

I cannot use the helmChart generator effectively, because it does not honor the namespace.

What are my remaining options?

The helm program does many many things, including (so I’m told) arbitrary execution of shell commands via --extra-args and particularly crafted Go templates.

The basic chart inflation kustomize performs is intentionally rudimentary to prove out the concept of performing “last mile” chart customization. Maintaining kustomize long term as a helm runner with full helm flag and argument knowledge as helm evolves would be toilsome and imply kustomize inherits whatever security risks helm presents.

So - anything that looks like what kustomize does should be done by kustomize, rather than delegated to helm, e.g. setting namespace (#3838).

The safest, most performant, and completely unlimited way to use kustomize + helm to generate config is

1. manually inflate the helm chart via helm template --foo --bar ... (with whatever risky options one wants),
2. commit the resulting plain old k8s YAML to a repo.
3. use kustomize to operate on that repo, treating it as a base, adding some last mile config changes.

From time to time, capture the latest chart, and repeat steps 1 and 2. It’s dangerous to set up a production stack that relies on kustomize to freshly download a helm chart with each build.

I have tried to define the namespace twice. Works with https://github.com/grafana/helm-charts/tree/main/charts/grafana

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: grafana-helm-test
helmCharts:
- name: grafana
  releaseName: customer-metrics-ui-v1
  repo: https://grafana.github.io/helm-charts
  namespace: grafana-helm-test
  version:  6.13.0

$ kustomize version
{Version:kustomize/v4.1.3 GitCommit:0f614e92f72f1b938a9171b964d90b197ca8fb68 BuildDate:2021-05-20T20:52:40Z GoOs:linux GoArch:amd64}

could you or one of the contributors reopen this issue @KnVerey

The helm program does many many things, including (so I’m told) arbitrary execution of shell commands via --extra-args and particularly crafted Go templates.

This is an issue with Helm’s --post-renderer option in particular and the scary part was that someone running kustomize didn’t have to consciously opt-in to run Helm. Given that we now have to explicitly elect to run Helm when we run kustomize, the user is consciously choosing to run Helm and accept the risks associated with it.

I think the namespace setting in kustomize should flow into the namespace setting of helm

This is a partially workable solution to me. The main places I could see it causing issues is with charts like Jenkins that create resources in other namespaces intentionally (in this case, creating a role in the agent namepace to allow Jenkins to spin up agent pods there).

From time to time, capture the latest chart, and repeat steps 1 and 2. It’s dangerous to set up a production stack that relies on kustomize to freshly download a helm chart with each build.

Perhaps if you’re pulling the Helm chart from an uncontrolled source. We pull specific versions of Helm charts into a private Helm repo and enforce tag immutability from there. We deploy multiple instances of a given application with different configurations and storing the fully templated code for each deployment adds a ton of noise and places for user error.