Use of Helm `lookup` function in secret management breaks compatibility with ArgoCD

[flippyboy]

Describe the Bug

In commit adcb27c, the Nautobot Helm chart introduced support for defining the database user from an existing Kubernetes secret when using an external database (postgresql.enabled=false and existingSecret provided). This change uses the Helm lookup function to dynamically fetch and validate the secret from the cluster, then populates environment variables like NAUTOBOT_DB_USER and NAUTOBOT_DB_PASSWORD using secretKeyRef.

While this enhances security for direct Helm deployments, it breaks compatibility with ArgoCD. ArgoCD does not support the Helm lookup function, as it requires contacting the destination cluster during template rendering, which ArgoCD's rendering process does not allow.

Expected Behavior

The chart should render successfully in ArgoCD without errors related to unsupported Helm functions.

Actual Behavior

When deploying via ArgoCD, the application fails to sync with errors indicating that the lookup function is not supported. This prevents users from using the chart in ArgoCD-managed environments.

Steps to Reproduce

1. Configure the Nautobot Helm chart with postgresql.enabled=false and provide an existingSecret for the database credentials.
2. Deploy the chart as an ArgoCD Application.
3. Observe sync failures due to the unsupported lookup function.

References

• Nautobot Helm chart commit introducing the change: adcb27c
• Related ArgoCD issue: argoproj/argo-cd#21745 (This is an open enhancement proposal to add support for lookup via a --helm-server-dry-run flag, but it's still in progress and not yet implemented.)

Suggested Fix

To maintain compatibility with ArgoCD (a common tool for GitOps deployments), consider one of the following:

• Make the lookup usage optional, controlled by a new value (e.g., useLookupFunction: true). When disabled, fall back to a non-lookup method, such as assuming the secret exists without validation or providing a warning in the docs.
• Document a workaround in the chart's README, such as using ArgoCD's Helm hooks or post-renderers to handle secret fetching externally.
• If feasible, explore alternative Helm patterns that avoid lookup entirely while still supporting existing secrets (e.g., using required for validation without cluster queries).

This would allow users to deploy Nautobot via ArgoCD without waiting for upstream fixes in ArgoCD.

Environment

• Nautobot Helm chart version: 3.0.1
• ArgoCD version: 3.2.0
• Kubernetes version: 1.34.1

Thanks for considering this! Let me know if more details are needed.

[tdelmas-lxp]

Hey, we are affected by this "lookup is blocked by ArgoCD" in release 3.0.0 and above. Would you be interested/agree to having a value flag skipLookupSecrets: true/false to check or not if the secrets do exists.

The issues come from these 2 instances of lookup:

https://github.com/nautobot/helm-charts/blob/v3.0.0/charts/nautobot/templates/_helpers.tpl#L168
https://github.com/nautobot/helm-charts/blob/v3.0.0/charts/nautobot/templates/_helpers.tpl#L222

and the workaround could be a wrapping if statement akin to:

{{- not .Values.skipLookupSecrets -}}
    {{- if .Values.nautobot.db.existingSecret  -}}
      {{- $secretObj := (lookup "v1" "Secret" .Release.Namespace .Values.nautobot.db.existingSecret) -}}
    {{- if not $secretObj }}
      ...
{{- end }}

Let me know and I'll submit a Pull Request in that sense. If not, do you have any plan to alleviate this issue or should we look for a solution on the argo side?

Best regards,
Thibault.

[ubajze]

@flippyboy, thank you for opening an issue. Also, @tdelmas-lxp, thank you for the input. There were holidays, so a little bit slower turnaround 😄

I tested this in our environment and I saw the same behaviour.

That is why, I just removed the lookup function. It brings more troubles than benefits. Please check the PR: #684

This change will come in the next patch release.