Support for private helm repositories about cluster-api-addon-provider-helm HOT 12 CLOSED

IMO CAAPH should mirror the feature of the underlying CAPI. i.e. if CAPI supports authentication to private image repositories, then we'd just use this same functionality to auth to the helm chart repository.

This sounds fair.

For me, this has became more like a nice-to-have. I'll test a couple workarounds such as mounting the secret. If it works then I think it's beneficial to be documented for other users that might need it. So i'll get back here after I get the time to test some workarounds

from cluster-api-addon-provider-helm.

/triage accepted

from cluster-api-addon-provider-helm.

This is a pretty interesting case, I haven't tried using private Helm repos but don't think it's currently supported. I'm wondering if we need to add an extra field or if the controller can be "smart" enough to figure it out. Would you need a secret ref to install a private Helm chart through helm install? Or would it just work automatically?

from cluster-api-addon-provider-helm.

I think I was a bit too fast to suggest adding a credentialsRef. I think it will be better to make the controller "smart" enough and it should be possible.

Would you need a secret ref to install a private Helm chart through helm install? Or would it just work automatically?

Not a helm guru here so take it with a grain of salt.
This depends a bit on how helm install is run.
If you do a helm repo add beforehand with the credentials and you install by chart reference: helm install mymaria example/mariadb then helm is "smart" enough to use the credentials passed during helm repo add. The credentials are stored at ~/.config/helm/repositories.yaml by default together with repo url etc. The location of the file can be different using the --repository-config flag.
If you install a chart using absolute url or using the --repo flag then you also need to pass the credentials using --password flag etc.

I'm not sure how CAAPH is handling it now, if the repo is added when a HCP resource is made etc.

An example of ~/.config/helm/repositories.yaml:

apiVersion: ""
generated: "0001-01-01T00:00:00Z"
repositories:
- caFile: ""
  certFile: ""
  insecure_skip_tls_verify: false
  keyFile: ""
  name: traefik
  pass_credentials_all: false
  password: ""
  url: https://traefik.github.io/charts
  username: ""
- (more entries...)

I think it should be possible to make the controller smart enough to figure it out:

• An operator could pass a list of helm repos/creds etc. The controller checks that list before adding a helm repo. If the helm repo is in that list then it adds the repo using the credentials etc of that list
• An operator could mount a secret similar to ~/.config/helm/repositories.yaml. The controller then checks if a helm repo is listed in that file and uses that config file for helm operations passing the --repository-config flag.
• ... Various way to tackle this depending on the current CAAPH implementation

( I'll try to mount a secret on ~/.config/helm/repositories.yaml and see how that goes. I'm expecting errors to occur during a possible helm repo add )

from cluster-api-addon-provider-helm.

Currently in CAAPH, we're fetching the kubeconfigs for the workload cluster and writing it to a file as seen in this code. The install client gets created here and I think you'd be able to pass the credentials. I think if you set up ~/.config/helm/repositories.yaml on the pod the controller runs on, it would probably be able to work but I haven't tried it yet.

I'd have to think on how we would design the user experience for passing in the password yet. Ideally, we could avoid adding the overhead of another resource by adding an optional field to the HelmChartProxy spec, but I'm not sure if that would cause security issues. Maybe we could create a secret with a label that indicates it contains creds for the Helm repo too.

from cluster-api-addon-provider-helm.

@Jont828 I currently dont have time to fully look into this. I've found a workaround for the time being and im mostly testing CAAPH to see if it fits our use case. If you have time to pick this up it would be great, otherwise ill try to tackle it when i get a bit more time. I might come back to you for input or clarifications

from cluster-api-addon-provider-helm.

No problem, I'll bring it up with some CAPI folks and see if anyone else has a similar use case, and from there I'll look into designing some way to support private repos. Just to clarify, did mounting the secret you mentioned work for you?

from cluster-api-addon-provider-helm.

did mounting the secret you mentioned work for you?

Haven't had time even for this unfortunately. I'll try to at least find some time to test this and come back to you.

from cluster-api-addon-provider-helm.

IMO CAAPH should mirror the feature of the underlying CAPI. i.e. if CAPI supports authentication to private image repositories, then we'd just use this same functionality to auth to the helm chart repository.

Else, as called out you should have a manual workaround such as by authenticating to the helm repository before you try to deploy.

@nikParasyr - happy to have a separate chat for your use case if you want to hit me up on kubernetes Slack

from cluster-api-addon-provider-helm.

That makes sense to me, if we can find a workaround for now that'd be great. As I mentioned in the other issue you opened, feel free to bring this up in the community call or Slack channel with other CAPI folks too.

from cluster-api-addon-provider-helm.

Any workaround on that?

from cluster-api-addon-provider-helm.

Thoughts on: #136 ?

from cluster-api-addon-provider-helm.