Support namespaceOverride configuration about helm-charts

[kfox1111]

If we only support one override, then just using helm's --namespace flag makes more sense to me.

But, I can see a need to install the privileged stuff in one namespace, and the unprivileged stuff in another, to properly utilize:
https://kubernetes.io/docs/concepts/security/pod-security-admission/

I'll want to deploy it in this way if possible.

[marcofranssen]

Why do we need a values file for this? This is simply done on the cli via --namespace, no need to put this in values files.

{{ .Release.Namespace }}

adheres to that commandline flag you give when doing helm install or helm upgrade, this looks like an anti-pattern to me. I have never seen a chart that defines the namespace in values.yaml.

[faisal-memon]

I see it in a lot of helm charts. Some examples:

• https://artifacthub.io/packages/helm/grafana/grafana
• https://artifacthub.io/packages/helm/kestra/kestra
• https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack
• https://artifacthub.io/packages/helm/cert-manager/cert-manager
• https://artifacthub.io/packages/helm/traefik/traefik

Its not a requirement, just a suggestion from what ive seen in other charts.

[marcofranssen]

Now really wondering why those charts are doing that 🤔 .

In general I always install charts like this.

helm upgrade -n spire-system --install --create-namespace --values my-values.yaml spire ./charts/spire
helm upgrade -n other-namespace --install --create-namespace --values my-values.yaml spire ./charts/spire
helm upgrade -n spire --install --create-namespace --values my-values.yaml spire ./charts/spire

This already gives me the chance to pick a namespace.

🤔

[marcofranssen]

@kfox1111 could you elaborate on that thought a bit with some example how you would utilize that? E.g. what goes in your privileged namespace and what in the unprivileged. This sounds very interesting.

We might even code defaults to split these things accross namespaces by default if we add pod-securty-admission to this chart.

[kfox1111]

Its a replacement of the PSP that some of us used to build multitenant clusters. In pod security admission, you can label your namespaces with one of the pod security standard values:
https://kubernetes.io/docs/concepts/security/pod-security-standards/

The two main ones we may want to deal with is:

1. Privileged - https://kubernetes.io/docs/concepts/security/pod-security-standards/#privileged
2. Restricted - https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted

They basically restrict what features of the pods can be used and/or linux capabilities. Like, a restricted pod can not run as uid0 nor mount hostpaths, along with a bunch of other stuff.

Ideally you'd have the most hardened standard possible on a pod for extra security.

The stuff that really does need hostPath would need to be privileged. (csi driver, agent daemonset) but stuff like the spire server probably doesn't, and could benefit from the extra hardening.