Security Model
Purpose and Scope
Airflow’s security model is built around explicit trust boundaries rather than a promise that every user-facing action is isolated from every other part of a deployment. The official security documentation frames this model in terms of deployment managers, DAG authors, authenticated UI users, non-authenticated UI users, and specialized roles such as admin, operations, connection-configuration, audit-log, regular, and viewer users. This page summarizes those boundaries for operators and extension authors, then maps the concepts to the repository files that expose permission names, provider auth-manager integration, and release-documentation publication flow. Sources: providers/common/compat/src/airflow/providers/common/compat/security/permissions.py, providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/security.py
A key practical point is that Airflow treats DAG code as powerful workload code. DAG authors can define tasks, call operators and hooks, and influence what workers execute. The security model therefore asks deployment managers to decide who may submit DAGs, how those DAGs reach the environment, which executor is used, and which runtime identities workers, triggerers, API servers, schedulers, and DAG processors receive. This matters because some deployment topologies intentionally share infrastructure, database access, or execution API resources, while stronger isolation requires additional platform controls outside normal DAG authoring.
The security model also distinguishes authorization inside Airflow from deployment hardening around Airflow. Airflow can check whether a user may access a UI view, operate on a DAG, or interact with a resource such as assets or backfills. It cannot by itself replace network policy, container isolation, secret-store policy, worker identity design, dependency review, or careful handling of administrator permissions. The official documentation explicitly calls out responsibilities for deployment managers, including protecting the installation, limiting DAG author capabilities, and limiting access for authenticated UI users.
Relevant Source Files
docs/images/documentation_architecture.py- Generates the documentation publication architecture diagram, showing release managers, committers, GitHub repositories, S3-backed live docs, CloudFront, and the public Airflow website as separate publication actors and infrastructure boundaries.providers/common/compat/src/airflow/providers/common/compat/security/__init__.py- Defines the provider compatibility security package namespace used by compatibility helpers.providers/common/compat/src/airflow/providers/common/compat/security/permissions.py- Provides compatibility resource constants for security permissions, including backfills, DAG versions, asset aliases, and Airflow-version-aware asset naming.providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/security.py- Implements a FastAPI dependency factory that authorizes FAB custom views through the active Airflow auth manager and returns HTTP 403 on denial.providers/fab/src/airflow/providers/fab/auth_manager/security_manager/__init__.py- Defines the FAB auth-manager security-manager package boundary.
Trust Boundaries and User Types
The most important trust boundary is between deployment managers and people who can contribute executable DAG code. Deployment managers own the Airflow installation and must choose how much DAG authors can affect scheduler-side parsing, worker-side execution, triggerer behavior, and access to shared configuration. DAG authors should be treated as trusted to run code in the contexts where their DAGs are executed unless the deployment adds stronger isolation. This is why the official security model lists executor-specific contexts such as local, Celery, Kubernetes, and triggerer execution rather than describing DAG files as inert configuration.
Authenticated UI users form a different boundary. They interact with Airflow through the UI or API, and their capabilities depend on the configured auth manager and granted permissions. Admin users can typically manage broad installation state, operations users may need runtime control, connection configuration users can affect sensitive integration details, audit log users inspect security-relevant history, and viewer users should be constrained to read-only information. Non-authenticated UI users should receive only the anonymous access that the deployment intentionally exposes, and production deployments should treat public exposure of the UI and API as a security-sensitive decision.
Airflow’s provider system has to keep permission terminology stable across core and provider packages. The compatibility permissions module defines concrete resource names such as RESOURCE_BACKFILL, RESOURCE_DAG_VERSION, and RESOURCE_ASSET_ALIAS. It also handles the version boundary around asset naming: for Airflow 3.0 and later it defines RESOURCE_ASSET as Assets, while older compatibility imports the dataset resource as the asset resource. That source-level behavior is small, but it reflects a larger contract: providers need to participate in authorization without breaking across Airflow versions. Sources: providers/common/compat/src/airflow/providers/common/compat/security/permissions.py
Authorization Surfaces in Code
The FAB provider’s FastAPI security helper shows how a request-time authorization check is wired. requires_fab_custom_view(method: str, resource_name: str) returns a dependency function. That dependency obtains the current user with get_user, asks the active auth manager from get_auth_manager() whether the user is authorized for the custom view, and raises HTTPException with status HTTP_403_FORBIDDEN and detail Forbidden if the decision is negative. The important design detail is delegation: the route-level helper does not embed role logic, but calls the configured auth manager. Sources: providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/security.py
This route-level pattern is a good model for extension authors. A provider or plugin should identify the method and resource it is protecting, retrieve the authenticated user through Airflow’s API security dependency, and rely on the auth manager for the authorization decision. That keeps UI and API extensions aligned with the deployment’s configured security policy. It also means denial is explicit and conventional: a caller who lacks permission receives a 403 response rather than the extension silently hiding an authorization failure or implementing a separate role system.
The package namespace files are intentionally minimal, but they still mark extension boundaries. providers/common/compat/src/airflow/providers/common/compat/security/__init__.py identifies the shared compatibility security namespace, while providers/fab/src/airflow/providers/fab/auth_manager/security_manager/__init__.py identifies the FAB security-manager package. For maintainers, these boundaries matter because security-sensitive helpers are imported by providers and UI integrations; public movement or renaming can create compatibility and authorization regressions even when the code body is small. Sources: providers/common/compat/src/airflow/providers/common/compat/security/init.py, providers/fab/src/airflow/providers/fab/auth_manager/security_manager/init.py
Deployment and Documentation Security Signals
The documentation architecture generator is not an auth component, but it is still useful security context for release and operations teams. It models release managers and committers as separate actors, the apache-airflow and apache-airflow-site repositories as separate GitHub assets, and the live documentation path through package-doc publishing, S3, CloudFront, and the public https://airflow.apache.org webserver. Security-sensitive documentation such as the security model, SBOM guidance, vulnerability handling, JWT authentication, Kerberos, Flower, and secrets masking must be published through this controlled path rather than treated as an informal side channel. Sources: docs/images/documentation_architecture.py
Operationally, the model reinforces defense in depth. Auth-manager checks protect API and UI actions, permission constants keep provider resources aligned with core names, and deployment managers enforce the runtime controls around networking, secrets, executors, images, dependencies, and DAG delivery. Sensitive information requires special attention: connection configuration can expose credentials or integration endpoints, secret masking reduces accidental disclosure in logs and UI rendering, and environment-variable-based secrets may not be maskable in the same way as values Airflow sees directly. These controls complement each other; none of them should be treated as sufficient alone.
Security-Sensitive Decisions Checklist
Use this checklist when reviewing an Airflow deployment or extension. First, identify who is allowed to deploy DAG files and whether those users are trusted to execute code in the selected executor and triggerer contexts. Second, verify that UI and API routes use the configured auth manager rather than local ad hoc checks. Third, map each provider or plugin resource to stable permission names, especially when supporting both Airflow 3.x assets and older dataset terminology. Fourth, decide who can configure connections and secrets, because those permissions are more powerful than ordinary read-only UI access.
Finally, document the boundaries that Airflow does not enforce for you. If workloads need team isolation, design it with executor isolation, separate credentials, network controls, Kubernetes namespaces or equivalent platform primitives, and carefully scoped database and secret-store access. Treat official security documentation as part of the deployment runbook, and keep the release path for that documentation protected. Related next steps are to read the pages on API authentication and JWT, secrets backends and masking, audit logs and vulnerabilities, Kerberos and workload security, and auth managers.