Use an Existing Secret for Proxy Variables in a Helm Chart

Reference complete proxy URLs from a Secret in the Helm 3 Deployment template instead of assuming a shell variable becomes container environment.

Suppose the release namespace already has a Secret named app-outbound-proxy. Its http_proxy and https_proxy keys contain the complete proxy URLs required by the application.

A Helm 3 chart can keep only that Secret’s name in values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

Inside the intended container’s Deployment template, reference the keys:

env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: http_proxy
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: https_proxy

This is a container-spec fragment. The Secret must exist in the Pod’s namespace and contain both referenced keys. Its values need to use the actual proxy listener’s protocol, host and port. For public application requests permitted to use an unauthenticated public proxy, build those URLs from a matching candidate in the free proxy list; retain any required direct exceptions.

The chart value supplies a name; secretKeyRef supplies the container’s environment values. Merely exporting HTTP_PROXY in the shell running helm does not add this env section to a Pod template.

Changing the Secret is a lifecycle change too

A container does not refresh its environment when Secret data changes. Arrange the intended restart or rollout so newly started containers receive updated values. Changing data under the same Secret name does not, by itself, edit the Deployment’s Pod template.

The application must support the chosen proxy environment variables. Helm repository access and the node’s image pull are separate consumers that run before this container environment can help them.

Related articles