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:
- I have to “login” twice:
helm repo add(forhelm dep up) andecho [creds] > ~/.netrc(for downloading the charts withcurl). - 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 pullwould first look for theindex.yamlas it was supposed to be, but mycurlcall will just use a hardcoded location for the.tgz, currently:<repo>/<chart-name>/<chart-name>-<chart-version>.tgz. - 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
- fix(helm): helm pull --repo to use repo creds from helm repos file Up to this point, helm pull --repo required --username and --password even if the repository had already been added via helm repo ad... — committed to andreaskaris/helm by andreaskaris 3 years ago
- fix(helm): helm pull --repo to use repo creds from helm repos file Up to this point, helm pull --repo required --username and --password even if the repository had already been added via helm repo ad... — committed to andreaskaris/helm by andreaskaris 3 years ago
- fix(helm): helm pull --repo to use repo creds from helm repos file Up to this point, helm pull --repo required --username and --password even if the repository had already been added via helm repo ad... — committed to andreaskaris/helm by andreaskaris 3 years ago
- fix(helm): helm pull --repo to use repo creds from helm repos file Up to this point, helm pull --repo required --username and --password even if the repository had already been added via helm repo ad... — committed to andreaskaris/helm by andreaskaris 3 years ago
- fix(helm): helm pull --repo to use repo creds from helm repos file Up to this point, helm pull --repo required --username and --password even if the repository had already been added via helm repo ad... — committed to felipecrs/helm by andreaskaris 3 years ago
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.jsonlike: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:The same I could have a file like
images.json:Which I my script could download each image using:
All fine so far. Now, what if both operations would require authentication?
For the docker case,
docker login ghcr.iowould make the trick. How about the helm one? This exact same situation is found under the workflow ofhelm dependency update/buildand 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.