ENV VAR Injection Issue while overriding ENTRYPOINT

Vault
1

Hi Friends,

Advanced Apologies if this does not below here! I am new to Vault and HashiCorp

As part of my project, I am integrating HashCorp Vault to our existing Reporting App which is based out of Redash

I have my live redash reporting app running on my openshift/K8 containers. Recently I am trying to integrate hashicorp vault to inject secrets as ENV VAR. As per Hashicorp Vault documentation, I am using this approach (Vault Agent Sidecar Injector Examples | Vault | HashiCorp Developer) to pass ENV VAR via ENTRYPOINT of Redash Dockerfile. Iam updating my Deployment COnfig on OC Web console to accompilish this, somehow my ENV VARs are not getting set on the containers. Below is the sample yaml which I am trying!. Why ENV VAR is not getting set?

YAML SNIPPET

[....]
    spec:
      containers:
        - resources: {}
          
          name: redash-reporting
          command:
            - /app/bin/docker-entrypoint &&  export AAA=123
          args:
            - server
[...]

REDASH DOCKER FILE’s ENTRYPOINT and CMD for Referencxe

[....]


ENTRYPOINT ["/app/bin/docker-entrypoint"]
CMD ["server"]

[Entry point file is this] (redash/docker-entrypoint at master · getredash/redash · GitHub)

2

Hi @abin-aot,

I guess you’re just testing it out by exporting a static variable in your example.

In order to get the variables exported from a Vault secret, you would need to add the appropriate annotations as described in the document you linked above.

You’d then need to replace the Pod spec command and args with

          command:
            ['sh', '-c']
          args:
            ['source /vault/secrets/config && /app/bin/docker-entrypoint server']

Where /vault/secrets/config contains variables templated from your secret.

In your case, it’s probably not working because you’re doing the export after the &&. The order is important.

3

Thanks for the reply, I made updates it’s working now. Can I assume like these ENV VAR won’t list on the K8’s POD console when I do printenv or env|sort ? Since it’s passed during deployment to the deployment pod!! @macmiranda thanks again

4

There’s no silver bullet in this case. If you have exec access into the pod you may as well just cat the file with the export statements.

To answer your question, yes, they won’t be accessible to a process that’s started in a separate shell but relying too much on this will just give you a false sense of security.

If you don’t rotate your secrets all that often, you can probably remove the /vault/secrets/config file from the container filesystem after using it and make the Vault agent an init-container only

In general, I’d recommend to remove exec access from anybody that’s not a cluster admin.