'~/.kube/config` incorrectly being a directory, changes the template results of some helm charts, and produces no warnings/errors.

[spkane]

What happened?

When kustomize build --enable-helm is run with a Kubeconfig that is actually a directory, the value of {{ .Release.Namespace }} is changing in some templates.

I was seeing some very strange results when doing testing, and after a lot of troubleshooting, I realized that an error in the test container had caused /root/.kube/config to be created as a directory inside the container, and this then triggered the template results to change without any errors or warning.

I am not 100% sure if the underlying issue handling this situation is in kustomize or helm. I got this far with my testing, but I have not tried to figure out if this reproduces with helm directly.

Also submitted here: helm/helm#12611

What did you expect to happen?

I would either expect the tool to produce an error or warning regarding the kube config issues while either rendering the helm templates exactly the same way as it normally would or quitting completely.

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

Create a new directory with these two files:

• kustomization.yaml

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

helmCharts:
  - name: testkube
    repo: https://kubeshop.github.io/helm-charts
    releaseName: testkube
    namespace: testkube
    version: 1.16.11
    valuesFile: helm-values.yaml

• helm-values.yaml

---
mongodb:
  enabled: true

testkube-api:
  nats:
    enabled: true

testkube-dashboard:
  enabled: true

testkube-operator:
  enabled: true
  namespace: testkube-system

• Test a build on a local system

$helm version
version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.21.4"}

$ kustomize version
v5.2.1

$ kustomize build --enable-helm | grep "namespace: default"
$

This output appears correct, as there are NO namespaces set to default.

But if we replace the kube config with a directory, the namespaces change and there are no errors, warnings, etc.

$ mv ~/.kube/config ~/.kube/config.bak
$ mkdir ~/.kube/config

$ kustomize build --enable-helm | grep "namespace: default"
  namespace: default
  namespace: default
  namespace: default
  namespace: default
  namespace: default
  namespace: default
  namespace: default
...

$ rmdir ~/.kube/config
$ mv ~/.kube/config.bak ~/.kube/config

Expected output

• A warning or error and no templates should have their namespace set to default.

Actual output

• There is no warning or error, and many templates have their namespace set to default.

Kustomize version

v5.2.1

Helm version

version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.21.4"}

Kubectl Version

Client Version: v1.28.4
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

Operating system

MacOS

[koba1t]

I can reproduce this problem, But I believe this problem is caused by the helm binary according to the comment below.
helm/helm#12611 (comment)

I think we need to wait for resolve at the helm.

/area helm
/triage out-of-scope

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[koba1t]

Please feel free to reopen this issue if you have any problems now!

/close

[k8s-ci-robot]

@koba1t: Closing this issue.

In response to this:

Please feel free to reopen this issue if you have any problems now!

/close

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.