Airflow Security Model¶
This document describes Airflow’s security model from the perspective of the Airflow user. It is intended to help users understand the security model and make informed decisions about how to deploy and manage Airflow.
If you would like to know how to report security vulnerabilities and how security reports are handled by the security team of Airflow, head to Airflow’s Security Policy.
Airflow security model - user types¶
The Airflow security model involves different types of users with varying access and capabilities:
While - in smaller installations - all the actions related to Airflow can be performed by a single user, in larger installations it is apparent that there different responsibilities, roles and capabilities that need to be separated.
This is why Airflow has the following user types:
Deployment Managers - overall responsible for the Airflow installation, security and configuration
Authenticated UI users - users that can access Airflow UI and API and interact with it
DAG Authors - responsible for creating DAGs and submitting them to Airflow
You can see more on how the user types influence Airflow’s architecture in Architecture Overview, including, seeing the diagrams of less and more complex deployments.
Deployment Managers¶
They have the highest level of access and control. They install and configure Airflow, and make decisions about technologies and permissions. They can potentially delete the entire installation and have access to all credentials. Deployment Managers can also decide to keep audits, backups and copies of information outside of Airflow, which are not covered by Airflow’s security model.
Authenticated UI users¶
They have access to the UI and API. See below for more details on the capabilities authenticated UI users may have.
Non-authenticated UI users¶
Airflow doesn’t support unauthenticated users by default. If allowed, potential vulnerabilities
must be assessed and addressed by the Deployment Manager. However, there are exceptions to this. The /health endpoint responsible to get health check updates should be publicly accessible. This is because other systems would want to retrieve that information. Another exception is the /login endpoint, as the users are expected to be unauthenticated to use it.
Capabilities of authenticated UI users¶
The capabilities of Authenticated UI users can vary depending on what roles have been configured by the Deployment Manager or Admin users as well as what permissions those roles have. Permissions on roles can be scoped as tightly as a single DAG, for example, or as broad as Admin. Below are four general categories to help conceptualize some of the capabilities authenticated users may have:
Admin users¶
They manage and grant permissions to other users, with full access to all UI capabilities. They can potentially execute code on workers by configuring connections and need to be trusted not to abuse these privileges. They have access to sensitive credentials and can modify them. By default, they don’t have access to system-level configuration. They should be trusted not to misuse sensitive information accessible through connection configuration. They also have the ability to create a Webserver Denial of Service situation and should be trusted not to misuse this capability.
Only admin users have access to audit logs.
Operations users¶
The primary difference between an operator and admin is the ability to manage and grant permissions to other users, and access audit logs - only admins are able to do this. Otherwise assume they have the same access as an admin.
Connection configuration users¶
They configure connections and potentially execute code on workers during DAG execution. Trust is required to prevent misuse of these privileges. They have full access to sensitive credentials stored in connections and can modify them. Access to sensitive information through connection configuration should be trusted not to be abused. They also have the ability to configure connections wrongly that might create a Webserver Denial of Service situations and specify insecure connection options which might create situations where executing DAGs will lead to arbitrary Remote Code Execution for some providers - either community released or custom ones.
Those users should be highly trusted not to misuse this capability.
Audit log users¶
They can view audit events for the whole Airflow installation.
Regular users¶
They can view and interact with the UI and API. They are able to view and edit DAGs, task instances, and DAG runs, and view task logs.
Viewer users¶
They can view information related to DAGs, in a read only fashion, task logs, and other relevant details. This role is suitable for users who require read-only access without the ability to trigger or modify DAGs.
Viewers also do not have permission to access audit logs.
For more information on the capabilities of authenticated UI users, see Access Control.
Responsibilities of Deployment Managers¶
As a Deployment Manager, you should be aware of the capabilities of DAG authors and make sure that you trust them not to abuse the capabilities they have. You should also make sure that you have properly configured the Airflow installation to prevent DAG authors from executing arbitrary code in the Scheduler and Webserver processes.
Deploying and protecting Airflow installation¶
Deployment Managers are also responsible for deploying airflow and make it accessible to the users in the way that follows best practices of secure deployment applicable to the organization where Airflow is deployed. This includes but is not limited to:
protecting communication using TLS/VPC and whatever network security is required by the organization that is deploying Airflow
applying rate-limiting and other forms of protections that is usually applied to web applications
applying authentication and authorization to the web application so that only known and authorized users can have access to Airflow
any kind of detection of unusual activity and protection against it
choosing the right session backend and configuring it properly including timeouts for the session
Limiting access for authenticated UI users¶
Deployment Managers also determine access levels and must understand the potential damage users can cause. Some Deployment Managers may further limit access through fine-grained privileges for the Authenticated UI users. However, these limitations are outside the basic Airflow’s security model and are at the discretion of Deployment Managers.
Examples of fine-grained access control include (but are not limited to):
Limiting login permissions: Restricting the accounts that users can log in with, allowing only specific accounts or roles belonging to access the Airflow system.
Access restrictions to views or DAGs: Controlling user access to certain views or specific DAGs, ensuring that users can only view or interact with authorized components.
Future: multi-tenancy isolation¶
These examples showcase ways in which Deployment Managers can refine and limit user privileges within Airflow, providing tighter control and ensuring that users have access only to the necessary components and functionalities based on their roles and responsibilities. However, fine-grained access control does not provide full isolation and separation of access to allow isolation of different user groups in a multi-tenant fashion yet. In future versions of Airflow, some fine-grained access control features could become part of the Airflow security model, as the Airflow community is working on a multi-tenant model currently.