tis-rpage

I think this is a bit of a mis-feature, as authentication can be established with repositories prior to kustomize being involved, ala `helm login`.

The environment variable for `HELM_REGISTRY_CONFIG` can be specified so that the registry authentication is available to kustomize so it's inherited by the helm subshell, and the pod can mount the...

`HELM_REGISTRY_CONFIG` uses the same json format pioneered by `DOCKER_CONFIG`. If you run a `helm login` it'll generate `${XDG_CONFIG_HOME}/helm/registry.json` which you can then mount into your pod and set the HELM_REGISTRY_CONFIG...

Don't try to hand create the file contents, use `helm login` to generate the contents. It should look something like this: ```json { "auths": { ".dkr.ecr.us-east-1.amazonaws.com": { "auth": "" },...

> @tis-rpage As I said above, it is not about the authentication. It's the format of the `helm pull` command. If you look at my working [diff](https://github.com/kubernetes-sigs/kustomize/issues/4335#issuecomment-1002868034) and take the...

> > The environment variable for HELM_REGISTRY_CONFIG can be specified so that the registry authentication is available to kustomize so it's inherited by the helm subshell, and the pod can...

> > If you pre-seed `charts/mychart` with your expanded repo, you can reference it via kustomize. > > I think "pre-seed" is where the disconnect may be. A lot of...

> /hold > > Having the test infra will be great, but it's also been pointed out to me that this is a hotfix for a particular use case. I'm...