This topic describes how to configure Airflow to secure your webserver.
Rendering Airflow UI in a Web Frame from another site¶
Using Airflow in a web frame is enabled by default. To disable this (and prevent click jacking attacks) set the below:
[webserver] x_frame_enabled = False
Disable Deployment Exposure Warning¶
Airflow warns when recent requests are made to
/robot.txt. To disable this warning set
False as below:
[webserver] warn_deployment_exposure = False
Sensitive Variable fields¶
Variable values that are deemed “sensitive” based on the variable name will be masked in the UI automatically. See Masking sensitive data for more details.
By default, Airflow requires users to specify a password prior to login. You can use the following CLI commands to create an account:
# create an admin user airflow users create \ --username admin \ --firstname Peter \ --lastname Parker \ --role Admin \ --email firstname.lastname@example.org
To deactivate the authentication and allow users to be identified as Anonymous, the following entry
$AIRFLOW_HOME/webserver_config.py needs to be set with the desired role that the Anonymous
user will have by default:
AUTH_ROLE_PUBLIC = 'Admin'
Be sure to checkout API for securing the API.
Airflow uses the config parser of Python. This config parser interpolates
‘%’-signs. Make sure escape any
% signs in your config file (but not
environment variables) as
%%, otherwise Airflow might leak these
passwords on a config parser exception to a log.
One of the simplest mechanisms for authentication is requiring users to specify a password before logging in.
Please use command line interface
airflow users create to create accounts, or do that in the UI.
Since Airflow 2.0, the default UI is the Flask App Builder RBAC. A
webserver_config.py configuration file
is automatically generated and can be used to configure the Airflow to support authentication
methods like OAuth, OpenID, LDAP, REMOTE_USER.
The default authentication option described in the Web Authentication section is related
with the following entry in the
AUTH_TYPE = AUTH_DB
Another way to create users is in the UI login page, allowing user self registration through a “Register” button.
The following entries in the
$AIRFLOW_HOME/webserver_config.py can be edited to make it possible:
AUTH_USER_REGISTRATION = True AUTH_USER_REGISTRATION_ROLE = "Desired Role For The Self Registered User" RECAPTCHA_PRIVATE_KEY = 'private_key' RECAPTCHA_PUBLIC_KEY = 'public_key' MAIL_SERVER = 'smtp.gmail.com' MAIL_USE_TLS = True MAIL_USERNAME = 'email@example.com' MAIL_PASSWORD = 'passwordformail' MAIL_DEFAULT_SENDER = 'firstname.lastname@example.org'
Flask-Mail needs to be installed through pip to allow user self registration since it is a
feature provided by the framework Flask-AppBuilder.
To support authentication through a third-party provider, the
AUTH_TYPE entry needs to be updated with the
desired option like OAuth, OpenID, LDAP, and the lines with references for the chosen option need to have
the comments removed and configured in the
For more details, please refer to Security section of FAB documentation.
SSL can be enabled by providing a certificate and key. Once enabled, be sure to use “https://” in your browser.
[webserver] web_server_ssl_cert = <path to cert> web_server_ssl_key = <path to key>
Enabling SSL will not automatically change the web server port. If you want to use the standard port 443, you’ll need to configure that too. Be aware that super user privileges (or cap_net_bind_service on Linux) are required to listen on port 443.
# Optionally, set the server to listen on the standard SSL port. web_server_port = 443 base_url = http://<hostname or IP>:443
Enable CeleryExecutor with SSL. Ensure you properly generate client and server certs and keys.
[celery] ssl_active = True ssl_key = <path to key> ssl_cert = <path to cert> ssl_cacert = <path to cacert>
Airflow can be configured to limit the number of authentication requests in a given time window. We are using
Flask-Limiter to achieve that and by default Airflow
uses per-webserver default limit of 5 requests per 40 second fixed window. By default no common storage for
rate limits is used between the gunicorn processes you run so rate-limit is applied separately for each process,
so assuming random distribution of the requests by gunicorn with single webserver instance and default 4
gunicorn workers, the effective rate limit is 5 x 4 = 20 requests per 40 second window (more or less).
However you can configure the rate limit to be shared between the processes by using rate limit storage via
RATELIMIT_* configuration settings in
For example, to use Redis as a rate limit storage you can use the following configuration (you need
redis_host to your Redis instance)
RATELIMIT_STORAGE_URI = 'redis://redis_host:6379/0
You can also configure other rate limit settings in
webserver_config.py - for more details, see the
Flask Limiter rate limit configuration.