Helm-chart error: exteranl redis + password + trivy

[qdrddr]

When enabled trivvy with external redis, the harbor helm-chart incorrectly handles secrets and the manifest inflation stage. FYI I'm using password with redis.

Example of the helm-value file when the issue manifests, with helm chart version 1.16.2:

trivy:
  enabled: true
redis:
  type: external
  external:
    addr: "myredis-svc:6379"
    existingSecret: "harbor-redis-mysecret"

kustomize build infra-deployments/harbor/kustomizations --enable-helm > infra-deployments/harbor/kustomizations/harbor.kustimized.yaml
Error: Error: template: harbor/templates/trivy/trivy-sts.yaml:29:28: executing "harbor/templates/trivy/trivy-sts.yaml" at <include (print $.Template.BasePath "/trivy/trivy-secret.yaml") .>: error calling include: template: harbor/templates/trivy/trivy-secret.yaml:11:15: executing "harbor/templates/trivy/trivy-secret.yaml" at <include "harbor.redis.urlForTrivy" .>: error calling include: template: harbor/templates/_helpers.tpl:225:48: executing "harbor.redis.urlForTrivy" at <include "harbor.redis.url" $>: error calling include: template: harbor/templates/_helpers.tpl:193:64: executing "harbor.redis.url" at <include "harbor.redis.cred" $>: error calling include: template: harbor/templates/_helpers.tpl:182:25: executing "harbor.redis.cred" at <include "harbor.redis.pwdfromsecret" $>: error calling include: template: harbor/templates/_helpers.tpl:176:56: executing "harbor.redis.pwdfromsecret" at <.Values.redis.external.existingSecret>: nil pointer evaluating interface {}.REDIS_PASSWORD

Use --debug flag to render out invalid YAML
: unable to run: 'helm template harbor infra-deployments/harbor/kustomizations/charts/harbor-1.16.2/harbor --namespace registry-cache -f /var/folders/5h/qvzp0mfx2jd1rsxg4f9z91880000gn/T/kustomize-helm-3858338458/harbor-kustomize-values.yaml --include-crds' with env=[HELM_CONFIG_HOME=/var/folders/5h/qvzp0mfx2jd1rsxg4f9z91880000gn/T/kustomize-helm-3858338458/helm HELM_CACHE_HOME=/var/folders/5h/qvzp0mfx2jd1rsxg4f9z91880000gn/T/kustomize-helm-3858338458/helm/.cache HELM_DATA_HOME=/var/folders/5h/qvzp0mfx2jd1rsxg4f9z91880000gn/T/kustomize-helm-3858338458/helm/.data] (is 'helm' installed?): exit status 1

The issue seems to be in the harbor/templates/_helpers.tpl with the definitions of harbor.redis.cred &harbor.redis.pwdfromsecret which tries to access Redis secret regardless if redis is deployed as external or internal. While it works fine when Redis is deployed internally, it fails when Redis is external since the secret does not exist in the inflation manifests by helm-chart, but will be accessible by the app when it is deployed in k8s.

trivy should use a secret generated by helm only if internal Redis is used in the value file, if external Redis is used, the chart should not try to pull the secret from the manifest.

[Eyalm321]

Hey guys im having the same issue, even when updating password as plaintext via redis.password it injects : infront of the password, also, redis.host is not working well with kubernetes services literals and it expects numbers, which makes the parseFloat command in url which crashes harbor. please fix.

[MinerYang]

Hi @qdrddr ,

This is a limitation from helm tools , more details please refer to #1894 (comment)

[github-actions]

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.

[cgrard]

I'm facing the same issue, don't know what to do about it at this point I'm stuck

[tim-van-dijkhuizen]

Bump, facing the same issue. I'm using the ExternalSecrets operator to import and create secrets asynchronously. When deploying this chart it tries to look up this secret and fails. When supplying an existing secret there is no need to lookup secret values. All other cases where an existing secret can be supplied work fine as the result of the lookup action is either not used or properly handled in case of existing secrets. Would be awesome if this could be changed as its preventing me from completing the HA setup guide. Thanks for the awesome chart otherwise, it works great!

[pisto]

The underlying issue is that the redis password is looked up in the template definition harbor.redis.urlForTrivy. This template is pulled if the .Values.redis.external.existingSecret is set. For all the other instances of *existingSecret, this is handled correctly )just the appropriate secret key references are made in the deployments). However for redis, the password is pulled to render some redis URLs and some other configuration (which in turn are in configmaps, not secrets!!! https://github.com/goharbor/harbor-helm/blob/main/templates/registry/registry-cm.yaml#L180 https://github.com/goharbor/harbor-helm/blob/main/templates/core/core-cm.yaml#L37-L38 https://github.com/goharbor/harbor-helm/blob/main/templates/jobservice/jobservice-cm.yaml#L22).

Since my use case is to render this chart via ArgoCD, as of now it is simply impossible to keep the redis secret out of the values and rendered templates, and I red

For configuration files that require the redis password, a solution would be to allow shell-style references to environment variables, and resolve those in an init container, presenting the interpolated values via shared emptyDir mounts, as it is done for example for the Alertmanager deployment in the Prometheus operator.

Referencing #2207 because I believe the issue is related (due to the essential brokenness of the lookup function in helm in my opinion).