Redis existingSecret rendering issue pending

[mlimardo1984]

Couple things:

• If you use helm template, lookup does not work

• as of now chart does not create any secrets by itself for redis internal or external

• Currently harbor requires full URL for redis for most of its components (so it's not possible to specify password in a separate env for most components, registry component being the exception here)

Technically we could add a check for empty value, but helm will not be able to template the url with value from existing secret, and your harbor will crash, having no password in the templated url

So, deploying with helm template and existingSecret for external redis is currently not supported

To do this properly two things would need to happen

1. All harbor components would need to have an ability to use the password from the separate env variable (just like registry component does) - and this would have to be in harbor itself, not the helm chart (you would need to create Issue in the main harbor repo)

2. Then Helm chart would need to adapt to that change and provide url without password, and separate env with password referencing existing secret

Originally posted by @Kajot-dev in #1641

Hello,

I'd like to know if there is any plan to do this implementation described above (Thanks @Kajot-dev !). With growing interest on this product and with the knowledge that many enterprise organization use tools like ArgoCD to deploy their application, i'd like to bring this up again and maybe start an initiative to implement the suggestion from @Kajot-dev .

Thank you

[MinerYang]

It is a limitation from the helm that for helm template itself could not talk with Kubernetes api .

• if static manifest rendering is preferred, you could use helm install --dry-run
• instead, helm install would not have this problem.

Understood some of the tools like ArgoCD heavily rely on helm template to rendering the resource manifest. Other helm app would also encounter this issue when using lookup.

I would like to take a look if there's any better way to basis checking existence secret requirement. Meanwhile, I think it is also reasonable to open an issue for the argocd side, since more like a behavior gap from helm controller side.

Best,
Miner

[Kajot-dev]

ArgoCD already had an issue about this since 2021 and I don't think it is going to improve anytime soon: argoproj/argo-cd#5202.

TLDR. I see two possible and viable solution to these problems.

1. Construct the redis url in container entrypoint

In container entrypoint if _REDIS_URL (and other redis-url env variables, like the core specifico one) are empty, then entrypoint could construct one using other variables, like REDIS_PASSWORD, REDIS_HOST, REDIS_PORT, REDIS_PROTOCOL, etc.

This way is 100% backwards compatible and other deployments can benefit from this. This would require a two-step approach

• Make a PR in https://github.com/goharbor/harbor as a backwards compatible change (to the image entrypoint)
  • Write a common script in https://github.com/goharbor/harbor/tree/main/make/photon/common
  • Execute the function in every related container entrypoint:
    • https://github.com/goharbor/harbor/blob/main/make/photon/core/entrypoint.sh
    • https://github.com/goharbor/harbor/blob/main/make/photon/jobservice/entrypoint.sh
    • https://github.com/goharbor/harbor/blob/main/make/photon/trivy-adapter/entrypoint.sh
• Make a PR to harbor-helm to start using the new feature

2. Use k8s env templating feature

This apprach uses a feature which enables us to template envs using other envs if they are defined directly in the env section of the object, like:

- name: _REDIS_URL
  value: redis://$(REDIS_HOST):6379/0
- name: REDIS_HOST
  value: *****

This approach has a limitation that would require to move redis related envs out of the configmap/secret and onto each Deployment object

Personally I am in favor of the first approach and can implement it in my free time, but before I do, I would like to at least hear some maintainer opinion if this has the chance to get merged.