#7792·crossplane

Support secretKeyRef/envFrom for extraEnvVarsCrossplane (and extraEnvVarsCrossplaneInit/RBACManager)

Author: Michael-hai1Created Sep 1, 2026Updated Sep 15, 2026

What problem are you facing?

The Helm chart's extraEnvVarsCrossplane (and the sibling fields extraEnvVarsCrossplaneInit, extraEnvVarsRBACManager) only support literal string values:

yaml
extraEnvVarsCrossplane:
  HTTP_PROXY: "http://user:[email protected]:8080"

This is rendered in templates/deployment.yaml as:

{{- range $key, $value := .Values.extraEnvVarsCrossplane }}
  - name: {{ $key | replace "." "_" }}
    value: {{ $value | quote }}
{{- end}}

There is no way to source one of these environment variables from a
Kubernetes Secret (valueFrom.secretKeyRef) or from a ConfigMap
(valueFrom.configMapKeyRef).

In our case this matters for the corporate egress proxy credential, which
every Crossplane pod needs as HTTP_PROXY/HTTPS_PROXY. Because
extraEnvVarsCrossplane only accepts literals, the only way to configure
it today is to commit the proxy username/password in plaintext into our
GitOps values repository (checked by an internal security scanner and
flagged as a hard-coded credential). We already use
valueFrom.secretKeyRef successfully for this exact secret in other
Crossplane sub-charts that expose a full env: list
(e.g. via providerControllerConfig.deploymentTemplate), so an
External-Secrets-Operator-backed Kubernetes Secret already exists  we
just can't reference it from the parent crossplane chart.

I confirmed this is still the case as of the latest stable release
(v2.4.0)  extraEnvVarsCrossplane in
cluster/charts/crossplane/values.yaml is unchanged.

I also searched existing issues/PRs for extraEnvVarsCrossplane,
secretKeyRef/envFrom, and related terms and found nothing tracking
this already.

How could Crossplane help solve your problem?

Allow each entry in extraEnvVarsCrossplane (and
extraEnvVarsCrossplaneInit / extraEnvVarsRBACManager) to optionally be
a valueFrom object instead of a plain string, e.g.:

extraEnvVarsCrossplane:
  HTTP_PROXY:
    valueFrom:
      secretKeyRef:
        name: beam-http-proxy
        key: proxy-url
  LOG_LEVEL: "debug"   # plain literals should keep working unchanged

with the template roughly becoming:

{{- range $key, $value := .Values.extraEnvVarsCrossplane }}
  - name: {{ $key | replace "." "_" }}
  {{- if kindIs "map" $value }}
    {{- toYaml $value | nindent 4 }}
  {{- else }}
    value: {{ $value | quote }}
  {{- end }}
{{- end}}

This would be fully backward compatible (existing literal-string values
keep working exactly as today) and would let users avoid committing
plaintext secrets to their GitOps repositories. Happy to open a PR for
this if the approach sounds reasonable.