helm: `helm pull --repo [url]` does not use the credentials set with `helm repo add`

When calling helm dependency update, or helm dependency build, helm will look for credentials in any repository set previously with helm repo add, no matter the alias given to the repository itself.

Such behavior is not retained when using helm pull --repo [url].

The problem is that I’m using helm pull to download charts in a script, but some of these repos needs credentials to be set. While helm dep up works fine, the helm pull --repo does not as it does not take the credentials I have set before with helm repo add. I can’t use helm pull --repo [url] --user [user] --password [pass] because I don’t always know beforehand which repo I’m going to download from in the script, and thus different credentials would need be used for each different repo.

To work around it, I switched from helm pull to curl with --netrc-optional, and instead of helm repo add, I’m setting the credentials in the ~/.netrc. The there are multiple caveats:

  1. I have to “login” twice: helm repo add (for helm dep up) and echo [creds] > ~/.netrc (for downloading the charts with curl).
  2. I have to build my own URL to fetch the chart, and while it’s working for me, there is no rule for the chart location in a repository. helm pull would first look for the index.yaml as it was supposed to be, but my curl call will just use a hardcoded location for the .tgz, currently: <repo>/<chart-name>/<chart-name>-<chart-version>.tgz.
  3. I can only set credentials per host, and not per repo, as it would be possible with helm repo add.

Output of helm version:

❯ helm version
version.BuildInfo{Version:"v3.5.3", GitCommit:"041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622", GitTreeState:"dirty", GoVersion:"go1.16.2"}

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 8
  • Comments: 35 (13 by maintainers)

Commits related to this issue

Most upvoted comments

I think there are enough stakeholders interested in this behaviour that it might be worth discussing the proposed solution in a HIP.

It sounds like there are a differing number of opinions, so it’s worth discussing those in a proposal so we can discuss the benefits and tradeoffs of each design.

I can provide clarity, let’s say I have a JSON file charts.json like:

[
  {
    "repo": "https://charts.jenkins.io",
    "name": "jenkins",
    "version": "3.3.20"
  }
]

Imagine this file is committed to one git repo (because of whatever reason).

Let’s say I have a script which iterates through this file, and downloads all the charts defined there. The charts could be downloaded by the script using helm pull:

$ helm pull --repo <json.repo> <json.name> --version <json.version>

The same I could have a file like images.json:

[
  {
    "registry": "ghcr.io",
    "name": "felipecrs/jenkins-agent-dind",
    "tag": "latest"
  }
]

Which I my script could download each image using:

$ docker pull <json.registry>/<json.name>:<json.tag>

All fine so far. Now, what if both operations would require authentication?

For the docker case, docker login ghcr.io would make the trick. How about the helm one? This exact same situation is found under the workflow of helm dependency update/build and it’s solved by doing what this issue proposes.

Hi @felipecrs. Let us know if you can determine a root cause for this issue. We’d welcome a patch to fix this behaviour.