spilo
spilo copied to clipboard
PATRONI_LOG_* environment variables are ignored.
It seems that most environment variables are removed before starting the patroni process. I was attempting to configure patroni to log to a directory (instead of stdout) by using the PATRONI_LOG_DIR
environment variable, but the runit/patroni/run
script seems to be working against me here:
# Only small subset of environment variables is allowed. We don't want accidentally disclose sensitive information
for E in $(printenv -0 | tr '\n' ' ' | sed 's/\x00/\n/g' | grep -vE '^(KUBERNETES_(SERVICE|PORT|ROLE)[_=]|((POD_(IP|NAMESPACE))|HOSTNAME|PATH|PGHOME|LC_ALL|ENABLE_PG_MON)=)' | sed 's/=.*//g'); do
unset $E
done
ref: https://github.com/zalando/spilo/blob/master/postgres-appliance/runit/patroni/run#L24-L26
Would it be possible to add |(PATRONI_LOG_.*=)
to the regex to allow PATRONI_LOG_* variables to be passed to the process?
You can always inject part of Patroni configuration via SPILO_CONFIGURATION
:
{"log":{"level":"DEBUG", ...}}
I am using the postgres kubernetes operator to manage the database. Unfortunately the operator does not provide a way to add custom config to SPILO_CONFIGURATION
. We could update the operator, do you think that is a better route to go? I think that changing both project would be the most flexible. Is there a reason we don't want to allow PATRONI_*
variables to be passed to patroni?
Is there a reason we don't want to allow PATRONI_* variables to be passed to patroni?
Yes, these variables may have some sensitive data that will be visible to Postgres. Exactly this is written in the comment to lines you are referring at: https://github.com/zalando/spilo/blob/823f1462219a8c0b28a63170987dd7ccdfedc3e0/postgres-appliance/runit/patroni/run#L23
I see, does patroni not strip out PATRONI_*
environment variables itself before starting postgres?
ref https://github.com/zalando/patroni/pull/1224 ref: https://github.com/zalando/patroni/blob/master/patroni/postgresql/postmaster.py#L215-L216
So shouldn't it be safe to be able to configure patroni using env vars (as is documented) and let it worry about removing them before starting postgres?
Made a quick PR here (https://github.com/zalando/spilo/pull/719) @CyberDem0n, let me know what you think.
@CyberDem0n any additional thoughts here? Are we unable to rely on patroni process to protect itself? If not, an alternative solution is here https://github.com/zalando/postgres-operator/pull/1857. Either one solves my needs.
any news to decrease log verbosity?