[QUESTION] Examples for helm repo authentication

[jmorsecode]

Would it be possible to elaborate further on the repository authentication usage?
From https://github.com/mgoltzsche/khelm#repository-configuration:

Repository credentials can be configured using Helm's repositories.yaml which can be passed through as Secret to generic build jobs.

The phrasing here implies this is optional but not a khelm default. I understand how a standard helm repositories.yaml functions, but how would this work with a full gitops workflow where the repo credentials are encrypted with KSOPS?

It would seem to be beneficial to have an example added showing how this would be implemented.

[mgoltzsche]

@jmorsecode thanks for creating the issue!

The phrasing here implies this is optional but not a khelm default.

Right, it is optional since khelm allows you to use any repo when HELM_REPOSITORY_CONFIG=/helm/repository/repositories.yaml is not present (default within the container) or KHELM_TRUST_ANY_REPO=true is set.

To give an example, imagine you have a repositories.yaml file (that you can generate using e.g. helm repo add):

repositories:
- name: fake
  url: https://example.org/repo/stable
  username: "fake-user"
  password: "fake-password"

You can make khelm use it as follows:

$ docker run --rm \
    -v "`pwd`/repositories.yaml:/repositories.yaml" \
    -e HELM_REPOSITORY_CONFIG=/repositories.yaml \
    mgoltzsche/khelm:2.2.1 template myrelease mychart --repo=https://example.org/repo/stable
Running khelm 2.2.1 (helm 3.10.1)
Using repository "https://example.org/repo/stable" (as user "fake-user")
...

The log message indicates that khelm uses the credentials from the mounted repositories.yaml.

However, khelm does not support an encrypted repositories.yaml file. When using khelm within the cluster, it requires you to store your repositories.yaml file within a Kubernetes Secret and mount it into the khelm container. When you want to store your repositories.yaml encrypted within a git repository and deploy it via GitOps, you could use a Kubernetes controller such as sealed-secrets that decrypts it within the cluster.
Since secret management in git is a cross-cutting concern or rather not specific to khelm, I don't think it makes sense to make khelm support it directly but to leverage other tools made specifically for that concern - unless somebody convinces me otherwise.

(Fwiw, there is an example showing how to use encrypted Helm values with the help of sops and the helm-secrets plugin but it doesn't apply to the repositories.yaml.)

[mgoltzsche]

I just realize that using the sealed-secrets controller in addition to KSOPS makes your setup more complex which I understand nobody wants. I didn't know that tool. Though, since khelm doesn't support decrypting the repositories.yaml currently, you'd need to let another tool decrypt it upfront somehow.
How do you imagine this should work ideally?

[mgoltzsche]

Adding a field to the generator config / generator.yaml to specify a custom repositories.yaml location would conflict with the requirement to let the file represent an allowlist of repositories a kustomization/chart can use (a Helm concept).

Instead, does it work for you to you let the env var HELM_REPOSITORY_CONFIG point to the location KSOPS writes the decrypted repositories.yaml file to?

[jmorsecode]

@mgoltzsche Thank you for the prompt replies! The generated repositories.yaml via ksops encrypted values is something I briefly considered. I have some light concern if it will play nice when run within a system like ArgoCD, but will just have to play around with it. IMO "ideally" it would be most consistent and intuitive to be able to simply set something like helm_username and helm_password at the same level of the of the repo in question requiring auth.