Specify custom basic auth header as secret

I'm using pomerium (installed via helm) to proxy access to an elasticsearch instance. I'm using set_request_headers to pass the basic auth token - the below works well. However, having a base64 encoded password directly in our config like this doesn't comply with our company security policies:

      policy:
      - from: https://kibana.with.auth.com
        to: http://kibana-kb-http.logging.svc.cluster.local:5601
        allowed_domains:
        - rob.com
        set_request_headers:
          Authorization: Basic blahblahblahblahblahblahblah
      - lots
      - of
      - others

Is there any way to provide that token/header as a kubernetes secret instead of directly in config?

I've tried Authorization: Basic ${ELASTIC_TOKEN} (and used extraEnvFrom to pass in as a secret) but it doesn't seem to resolve the env. I've also been looking at encoding the whole config and passing that in as a secret, but it makes adding new policies in the future a complete pain.

Any ideas on how I could do this? Or other ideas for setting this header?

Hi @robertgates55,

base64 encoded password directly in our config

The pomerium configuration is stored as a kubernetes secret partially for this reason. Inline credentials are no less safe than any other runtime secrets you might be storing in the cluster. Does that address your concern?

The configuration file is not interpolated for environment variables at runtime. The policy block is, however, template evaluated

pomerium-helm/charts/pomerium/templates/_helpers.tpl

Lines 463 to 469 in 2c1b3d3

    
           {{-    if kindIs "string" .Values.config.policy }} 
        
           {{       tpl .Values.config.policy . | indent 2 }} 
        
           {{-    else }} 
        
           {{       tpl (toYaml .Values.config.policy) . | indent 2 }} 
        
           {{-    end  }} 
        
           {{- end }} 
        
           {{- end -}}

if that helps at all. You should have access to the helm templating functions if you need to do something more advanced during chart rendering.

When you say 'at runtime', do you mean at helm upgrade time, or actually inside the container at runtime? If the latter, how do I need to present the env in config to make pomerium interpolate it?

Some more background:

We use gitops to manage all our clusters, and our general practice with things like this is to create a secret (we use bitnami sealed-secrets to enable this) containing eg the password.
Then in the helm config, if supported, we'd reference that secret by name (eg useExistingSecret: true, secretRef: my-super-secret-password)
For charts that don't support such a pattern, we often use extraEnvs fields to put the password in an env, and then provide the helm value like eg creds: username:$MY_SUPER_SECRET_PASSWORD

When you say 'at runtime', do you mean at helm upgrade time

Helm upgrade time. You could possibly use the helm lookup function but that does still copy the value into the pomerium secret when helm runs.

Some more background...

I understand the use case/pattern. Thanks for clarifying. I don't think there's anything currently implemented that will support that type of usage. Will give this some consideration.

Any update on this? Or new patterns to achieve the same thing?

Closing this in favor of pomerium/pomerium#1781 to keep the conversation centralized

	{{- if kindIs "string" .Values.config.policy }}
	{{ tpl .Values.config.policy . \| indent 2 }}
	{{- else }}
	{{ tpl (toYaml .Values.config.policy) . \| indent 2 }}
	{{- end }}
	{{- end }}
	{{- end -}}