expose.tls.certSource "none" generates inconsistent errors

[MathiasAkerberg]

Trying to achieve tls termination in my Ingress without specifying a secret, instead relying on the default ingress cert.

Setting the property expose.tls.certSource to none seems strangely to work as expected if not using persistence existingClaim for the componentes. Otherwise, following error message is generated:

Failed to install app harbor-v5sc7. Error: error while running post render on files: error while running command /kustomize.sh. error output: 2020/11/11 14:39:40 nil value at secret.secretName ignored in mutation attempt Error: <nil> is expected to be either a string or a []interface{} : exit status 1

[ywk253100]

I didn't get your point clearly. Does setting the expose.tls.certSource to none work for you? What settings cause the error you provided?

[MathiasAkerberg]

Ah, sorry for not being clear enough.

expose.tls.certSource to none seems to work if not using the property persistence.persistentVolumeClaim.XXX.existingClaim.

Maybe I am configure something wrong, but I suspect there might be a bug? Most likely in the Helm template. Gets the same error even if expose.tls.secret.secretName is set or not.

[SoarinFerret]

I experienced the same issue, reproducible on multiple clusters with the following answers file:

externalURL: "https://cr.example.com"
expose:
  type: ingress
  tls:
    enabled: true
    certSource: none
  ingress:
    hosts:
      core: cr.example.com
      notary: notary.example.com

I am currently using traefikv2 as my ingress for our clusters, so I let it manage the TLS certs. So, correct me if I'm wrong, that's the config the documentation recommends? However, after looking at the code, it looks like TLS should only be enabled when setting certSource to anything but none. Here is an example:

https://github.com/goharbor/harbor-helm/blob/6f1ab30cb1e5ef55dbacf2d66829aa0ca340f670/templates/_helpers.tpl#L557-L562

https://github.com/goharbor/harbor-helm/blob/f97f50612302c0f034c8b9b3c91d1433afd5919d/templates/ingress/ingress.yaml#L52-L60

How I read that is it's going to set the harbor.tlsCoreSecretForIngress to nothing, however if TLS is enabled, it is required to have some value for spec.tls[0].secretName within the ingress. It appears there are a few scenarios where this is the case.

I came across all this while investigating a separate issue I am having, and a stackoverflow post led me to believe my TLS settings may be an issue. I don't think that was actually the case, but maybe the research I did here will help someone else!

[ywk253100]

@MathiasAkerberg I cannot reproduce the issue in my environment. Is the error reported by kustomize? Is it possible related with kustomize?

[MathiasAkerberg]

I suspect so. The error occured in my Rancher environment from which I was deploying Harbor through the Rancher concept "Catalog App". I'm pretty sure Helm is used under the surface and if I'm not wrong, isn't Kustomize used as a sub-component for some Helm features?

[MathiasAkerberg]

Just tried to implement the corresponding setup with Harbor in my local environment (using Helm CLI against a local k8s context), and did not succeed to reflect the problem either.

I installed Harbor with no existing claims (create during deployment) as well as existing, with the expose.tls.certSource to "none" and it works as expected.

So the error may be isolated to how Rancher manages the installations under the hood. I don't know if you think it's worthwile to get deeper into this... But it may be in your interest to take it further, considering Rancher's growth as a Kubernetes cluster management platform for Startups as well as Enterprises.

[ayoubeddafali]

I'm having the same issue using rancher, with persistence disabled.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.