airflow-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [airflow] NBardelot edited a comment on issue #6801: [AIRFLOW-6260] Drive _cmd config options by env var
Date Tue, 17 Dec 2019 14:05:53 GMT
NBardelot edited a comment on issue #6801: [AIRFLOW-6260] Drive _cmd config options by env
   I think all your points come to evaluating the core concept of sensitive data management
in containers. IMHO that's not really a debate (or it would imply having it with the Kubernetes
project itself). As-is, it is a best practice that sensitive data should only be stored in
secrets. Secrets and configmaps are managed alongside with the application's deployment. 
   With the current Airflow design the only clean way to convey a configuration that includes
sensitive data (user/password for the broker, the database etc.) is to provide the whole airflow.cfg
file as a secret. That comes with huge drawbacks:
     * all non-sensitive data cannot be read/analyzed readily anymore
     * you cannot reuse secrets (if the database password is present in two fields, that's
two locations where you need to manage it... instead of one secret)
     * you need a tool to generate the airflow.cfg from a template, since you do not want
to store the version with sensitive data anywhere in clear-text
   It is far better to manage your database password in only one secret, and the script that
computes the connection string as a configmap that does not contain the secret in clear-text.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message