NBardelot edited a comment on issue #6801: [AIRFLOW-6260] Drive _cmd config options by env var URL: https://github.com/apache/airflow/pull/6801#issuecomment-566553394 @potiuk 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). 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: you would provide the same configmaps and secrets to all your Airflow components, the same way you would provide them with the same environment variables or airflow.cfg file. 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.) to Airflow containers in Kubernetes 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: us...@infra.apache.org With regards, Apache Git Services
