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)
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.
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
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.