Securing a self-hosted Airflow in depth: the trust model for DAG authors, worker isolation through the Task Execution API, JWT and API access, encryption and masking of secrets, multi-team limits and audit logs.
Why anyone who can merge DAG code can run code on workers and touch every DAG: the user types in the Airflow security model, what Airflow does not sandbox, and the review, repository and deployment controls that follow from it.
Designing Airflow 3 so workers never hold database credentials: the Task Execution API, short-lived execution tokens, asymmetric JWT keys, network policies, environment variables versus files and the edge worker exception.
Using the experimental multi-team mode from Airflow 3.2: team-scoped RBAC, variables and connections, what teams still share, managed services that do not support it, and when separate Airflow instances are the safer choice.
What the default Simple auth manager does and does not provide: fixed roles, generated passwords, the all-admins switch, and choosing FAB, Keycloak or AWS auth managers before go-live.
Authenticating scripts and services against the Airflow 3 REST API: getting tokens from the auth manager, cookie versus bearer credentials, token refresh, service accounts and the 3.3.2 precedence change.
Protecting connection and variable passwords at rest: generating and storing the Fernet key, the three-step rotation with airflow rotate-fernet-key, Kubernetes Secret handling and when a secrets backend replaces stored credentials.
How Airflow redacts passwords and tokens: which names trigger masking, extending the keyword list, mask_secret in custom code, and the gaps through XCom and environment variables that need other controls.
What Airflow records about who did what: UI, API and CLI actions, system events, reading logs through the UI or /eventLogs, the permission to view them, retention against database cleanup and shipping them to a SIEM.
Keeping credentials out of the metadata database with a secrets backend: lookup order, Vault, AWS, Azure, GCP and Kubernetes backends, a separate backend for workers, and naming conventions that avoid collisions.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.