I am using Vault Secrets Injection Webhook for delivering secrets directly into pods. It is a mutating webhook which injects its binary into a pod for delivering secrets in such a way that the secrets are delivered not listed in env. More info on how it works is at the above link.
The problem with Redis-HA chart is that it is using ${AUTH} shell variable in split-brain-fix container and perhaps in the other parts, which are using the check from lib.sh. If I get it right, the script is not permanently running, but is executed periodically, and therefore it does not have access to the actual value of ${AUTH} from env due to Vault Secrets Injection Webhook.
The solution could be to make lib.sh functions read Redis password from /data/conf/redis.conf, not from env variables.
At the moment I have to partially compromise security by storing Redis password in a k8s secret.
The above may apply to Sentinel password as well.
I am using Vault Secrets Injection Webhook for delivering secrets directly into pods. It is a mutating webhook which injects its binary into a pod for delivering secrets in such a way that the secrets are delivered not listed in env. More info on how it works is at the above link.
The problem with Redis-HA chart is that it is using
${AUTH}shell variable insplit-brain-fixcontainer and perhaps in the other parts, which are using the check fromlib.sh. If I get it right, the script is not permanently running, but is executed periodically, and therefore it does not have access to the actual value of${AUTH}from env due to Vault Secrets Injection Webhook.The solution could be to make
lib.shfunctions read Redis password from/data/conf/redis.conf, not from env variables.At the moment I have to partially compromise security by storing Redis password in a k8s secret.
The above may apply to Sentinel password as well.