Why the Airflow Simple auth manager is not for production
The Simple auth manager is intended for development and testing, so a fresh Airflow 3 install that signs people in with it should not go to production as it is. Airflow 3 uses the Simple auth manager by default, and only one auth manager can be active at a time, selected through the auth_manager option. That means the choice of sign-in model is made when you configure the platform, and it shapes everything after it: who can see DAG code, who can trigger or pause runs, and how access is reviewed later.
The Simple auth manager gives you four fixed roles (viewer, user, op and admin) and defines users as username:role pairs. Its passwords are generated and written to a file, which makes account lifecycle, password rotation and offboarding manual work that sits outside your identity system. The simple_auth_manager_all_admins setting is more serious: when it is set to True, Airflow authentication is disabled and anyone who opens the UI is logged in as an admin. Confirm that this setting is absent or False in every environment, including the ones built from copied configuration files.
Before go-live, decide which auth manager your organization will run and document the role mapping from your identity groups to Airflow roles. The options are the FAB auth manager, which comes from the FAB provider, Keycloak, or the AWS auth manager, each with its own configuration. Plan the sign-in configuration together with the identity provider, since OAuth callback URLs change under /auth in Airflow 3 and must be updated. Read the Simple auth manager documentation to confirm the current limits before you finalize the design.
What the Simple auth manager does and does not provide
The Simple auth manager gives a new Airflow 3 install a working login with almost no setup, which is why it is the default. The cards below separate what it does provide from what production identity needs, so you can judge the gaps against your own access model before go-live.
Four fixed roles
The Simple auth manager ships four roles: viewer, user, op and admin. Every permission in the UI and API maps to one of these, and you cannot add a role that matches a team's actual duties. A data engineer who needs to trigger one team's DAGs but not edit connections for everyone ends up with either too little or too much access. Map your required duties to these four roles on paper before you rely on them.
Users as username:role pairs
Users are declared in configuration as username:role pairs rather than being created and governed in a directory. There is no link to the people who own those accounts, so a leaver's access is removed only when someone edits the configuration and redeploys. Ask who owns that change, how it is reviewed, and how quickly it is applied across every environment.
Generated passwords in a file
Passwords are auto-generated and written to a file on the Airflow host. That file becomes a credential store with its own exposure: it can be copied into backups, shown in tickets, or left readable on a shared volume. Confirm the file location for your version, restrict who can read it, and plan how the initial credentials are delivered and then rotated.
No identity provider mapping
The Simple auth manager does not map groups or claims from your identity provider to Airflow roles. Your existing group structure, such as which team owns which DAGs, has no effect on what a user can see or do. Joining, moving teams and leaving all become manual Airflow changes. Confirm this against the auth manager docs for the version you run before you accept it as a gap.
Authentication controls to confirm
Items such as multi-factor authentication, session lifetime, password policy and account lockout are not what this auth manager is built to provide, and your identity provider is where those controls normally live. Treat each as an open question and check the Simple auth manager documentation for the version in use. Record the answer in your security review rather than assuming the control exists.
All-admins switch
Setting simple_auth_manager_all_admins to True disables authentication, so anyone who reaches the UI is logged in as an admin. The setting is meant for local testing, but it is easy to carry from a test values file into a shared environment. Check every deployed configuration for this key and alert on it in your configuration review.
What the all-admins switch does to your UI and API
Setting simple_auth_manager_all_admins to True turns off Airflow authentication. Anyone who can reach the UI is logged in as an admin without a username or password, and the same applies to the API endpoints that the UI calls. The switch does not weaken a role, it removes the login step entirely, so every role check that the Simple auth manager performs is bypassed for every visitor.
The setting tends to appear for reasons that feel temporary. Someone sets it while troubleshooting a login loop, a broken callback or a locked-out user, and forgets to revert it. A config file copied from a laptop or a test cluster carries it into a shared environment, or a Helm values file or environment variable override carries it into production. Because the switch lives in configuration rather than in code review history, a change like this is easy to miss. In practice, network reachability becomes the only control: anyone on the internal network, a misrouted ingress, or a port exposed through a load balancer gets full administrative control over DAGs, connections and variables.
Treat this as a configuration gate to verify, not a one-time fix. Check the effective value in every environment, including what the running API server and the rendered container or Helm configuration actually load, not only the file in the repository. Add the check to deployment pipelines so a release fails when the setting is True outside a sandbox, and confirm with your team which environments are allowed to run without authentication at all. Illustrative example: a staging cluster is reachable from a corporate VPN, and an admin enabled the switch during an incident. If nobody checks the running configuration, every VPN user gains admin rights to production connections until someone notices.
Choosing an auth manager for production
This table compares the Simple auth manager, the FAB auth manager, Keycloak and the AWS auth manager by identity source, role model, operational footprint and setup. Use it to narrow the choice before go-live, then follow the dedicated authentication pages for the configuration each option needs.
| Criterion | Simple auth manager | FAB auth manager | Keycloak or AWS auth manager |
|---|---|---|---|
| Intended use | Development and testing only, per the Airflow docs | Production use with local or database-backed users and roles | Production use with an external identity provider |
| Identity source | Usernames defined in configuration, with generated passwords written to a file | Users stored in the Airflow metadata database, with optional LDAP or OAuth configuration | Your central identity provider or the AWS account identity model |
| Role model | Four fixed roles: viewer, user, op and admin | Configurable roles managed inside Airflow | Roles mapped from identity provider groups or AWS permissions, to confirm per option |
| Installation | Included in Airflow 3 by default, no extra package | Requires the FAB provider package and FabAuthManager | Requires the matching provider configuration and identity provider setup |
| Operational footprint | Lowest, but it has no password lifecycle, MFA or offboarding controls | Adds user administration inside Airflow that your team must maintain | Adds an identity provider to operate, or depends on AWS account administration |
| Auth routes and callbacks | Local login only | Confirm the OAuth callback URLs after the move to the /auth routes in Airflow 3 | Callback URLs must match the provider registration exactly |
| Audit and offboarding | Confirm how user removal is handled before go-live | Confirm how user removal is logged and reviewed | Access removal follows the identity provider, so confirm the process with your IAM team |
| Before go-live | Replace it, because the all-admins switch can disable login entirely | Confirm the provider package version and role mapping | Confirm the identity integration and role mapping with a test tenant |
How to move off the Simple auth manager before go-live
This sequence replaces the development-only Simple auth manager with a production auth manager that your identity provider controls, and it gives you a check at each step so you can show the change was made and verified.
Inventory auth settings in every environment
Someone on the platform team lists every Airflow environment (development, test, staging, production) and records the effective auth_manager value, whether simple_auth_manager_all_admins is set, and where each value comes from, such as airflow.cfg, an environment variable or a Helm values file. Check each environment's running configuration through the deployed API server, not only the file in the repository, because environment variables override the file. The step is done when every environment has a written record with no unexplained values.
Choose the production auth manager
The security owner and platform lead choose one auth manager for production, based on the identity provider the organization already runs and the auth managers that fit it: FAB, Keycloak or AWS. Confirm with the identity team which protocol, group claims and session lifetimes they can provide, and confirm the chosen provider's configuration requirements in the Airflow documentation for your version. The step is done when a signed decision record names the auth manager, the identity source and the owner of the configuration.
Set the auth manager explicitly
The platform engineer sets the auth_manager option to the chosen provider in every production environment, and sets simple_auth_manager_all_admins to disabled or removes it. Airflow allows only one auth manager at a time, so an explicit setting prevents an environment from silently falling back to the default. Deploy to staging first and confirm the API server starts and logs the expected auth manager. The step is done when staging starts cleanly with the intended value and no all-admins setting remains.
Map identity provider groups to Airflow roles
The identity engineer and the Airflow owner define which identity provider groups map to which Airflow roles, and document the mapping as code or reviewed configuration. Start from least privilege and grant admin rights to a small, named group. Test each mapped group with a test account and confirm that users see only the actions their role allows. The step is done when every test account in each group reaches the expected pages and is denied the rest, and the mapping file is under version control.
Update OAuth callback URLs for the /auth routes
Because Airflow 3 moves auth routes under /auth, the identity administrator updates the redirect or callback URLs registered with the identity provider to match the new paths, in every environment. Old URLs can break sign-in silently or send users to an error page. Check each registered redirect URI against the paths the API server exposes after deployment, and remove any stale entries that point to earlier paths. The step is done when a sign-in succeeds in each environment and the identity provider shows no failed redirects in its logs.
Verify that unauthenticated access is refused
A tester opens the UI, the REST API and any API endpoint used by scripts in a private browser session and without credentials, then confirms that each request is refused or redirected to sign-in. The tester also confirms that a user with a low-privilege role cannot reach admin-only pages or actions. Record the results with the date, environment and tester name. The step is done when every protected route returns a refusal in the evidence record, and any gap is fixed and retested before go-live.
Confirm the change is recorded and repeatable
The platform lead confirms that the auth configuration is stored in version control or the deployment pipeline, that changes to it go through review, and that the sign-in and access events are visible in the logs your team reviews. Ask the security owner to sign off on the test evidence and the role mapping. The step is done when a redeployment from the repository reproduces the same auth behavior and the sign-off is filed with the go-live record.
What changes when you upgrade from Airflow 2 to Airflow 3
If your current Airflow 2 installation uses the FAB auth manager, the upgrade changes your sign-in path as well as the platform, so plan both together. In Airflow 3, auth routes move under /auth, which means OAuth callback URLs registered with your identity provider must be updated before users can sign in again. Inventory every registered redirect URI now, including those for test and staging environments, because a missed callback fails at login rather than during the upgrade itself. The Airflow 3 upgrade guide documents the route change and the related auth settings.
The upgrade path also has a hard prerequisite. The upgrade guide requires being on Airflow 2.7 or later before moving to Airflow 3, and it recommends moving to the latest 2.x release first and checking DAG code with the Ruff AIR301 and AIR302 rules. FAB is no longer bundled as the default. It now comes from the FAB provider, and you must select FabAuthManager explicitly through the auth_manager option. Confirm the provider version pinned in your constraints file matches the Airflow release you are targeting, and record which identity provider settings you will carry across.
Airflow 2 reached end of life on April 22, 2026, so it no longer receives fixes of any kind. Teams still running it need a single plan that covers the platform upgrade, the auth manager decision and the callback change, with a dated cutover and a rollback path for the metadata database. Ask whoever owns the upgrade to confirm whether the auth change will be tested in staging with real identity provider settings, and whether the Simple auth manager will be used anywhere in the interim. Treat that interim use as a risk to record, since the Simple auth manager is intended for development and testing.
Security and operational risks to control
The Simple auth manager is built for development and testing, so its gaps show up as operational risks once real users and data arrive. The cards below cover what to control before go-live and how to confirm each control works in your environment.
Exposed UI without login
The UI can be reachable with no sign-in if simple_auth_manager_all_admins is set to True, because every visitor is logged in as an admin. Check the effective configuration on every API server replica, not only the Helm values or the file you edited. Then confirm from outside the network boundary that an unauthenticated request to the UI and API is refused, and record the result as evidence.
Generated password files
The Simple auth manager writes generated passwords to a file on the API server. Confirm where that file lands in your container image, volume or VM, who can read it, and whether it is captured by image layers, shared volumes or backups. Rotate or remove any password that was generated before go-live, and test that the file is absent from the running environment after the first start.
Shared admin accounts
Defining users as username:role pairs is simple, but a team that shares one admin login cannot tell who changed a DAG, a connection or a variable. Require one named account per person, remove generic accounts, and test by performing a change as a named user and checking that the audit record shows that identity. Accountability depends on this test, not on the number of accounts.
Roles too broad for operators
The four fixed roles (viewer, user, op and admin) cannot separate duties by team or DAG, so an operator who needs to clear task state may also be able to change access or configuration. Write down which actions each role must allow and deny, then confirm them with a test user for each role. Ask whether a finer model, such as the FAB or an external provider, is needed before you go live.
Session and token handling
Sessions and API tokens issued by the Simple auth manager need the same lifetime, revocation and transport checks as any production login. Confirm that sessions expire after inactivity, that a removed user loses access on the next request, and that the UI and API are served only over TLS. Test these with a real revocation, because a passing login test does not prove that access ends when a user leaves.
Questions teams ask before replacing the Simple auth manager
How much effort does replacing the Simple auth manager take?
The effort depends on four things: the identity provider you connect, how many roles you need to map, how many environments must be configured, and how far along your Airflow upgrade already is. Each auth manager is a separate choice, so the work starts with picking one (FAB, Keycloak or the AWS auth manager) and confirming its configuration needs. A single production instance with a small set of roles is a much smaller job than several environments with custom role sets and OAuth callbacks to update. Ask any partner to size the work against your identity provider and role model in writing, not from a general estimate.
Can an in-house team switch auth managers without a partner?
Yes, if the team has experience with Airflow configuration and the identity provider involved. The switch involves setting the auth_manager option, installing the FAB provider when you use FAB, mapping identity groups to Airflow roles, and updating OAuth callback URLs because Airflow 3 moves auth routes under /auth. Teams without recent OIDC or SAML work often find the redirect, token and role mapping steps take longer than the Airflow changes themselves. An outside partner is most useful for the identity integration and for review of the role model before users depend on it.
What does the switch need from our own staff?
Plan for three groups of people. Identity administrators own the identity provider, client registrations, group membership and any MFA policy. Airflow administrators own the auth manager settings, role mapping and the DAG and connection access each role grants. A test environment that mirrors production's identity provider and Airflow version lets you check logins, role access and API calls before cutover. Name an owner for each group before the project starts, because most delays come from waiting on an approval or a group decision.
Can we keep the Simple auth manager for a pilot?
A pilot can use it only if access is limited to people who would be allowed to use a development system. The Simple auth manager is intended for development and testing, uses four fixed roles, and writes generated passwords to a file. Setting simple_auth_manager_all_admins to True removes authentication entirely, so anyone who can reach the UI becomes an admin. Keep pilots on a network segment without production data or production connections, and set a date to move the pilot to a supported auth manager before any real users or credentials are added.
Which auth manager should we choose before go-live?
Choose based on the identity system you already run and how much role control you need. FAB is the option to consider when you want Airflow's own role model, and it comes from the FAB provider and its FabAuthManager class. Keycloak fits organizations that already run Keycloak as their identity provider for single sign-on. The AWS auth manager fits teams that already manage access through AWS identities. Confirm the supported identity protocols and role mapping details against the Airflow auth manager documentation for your exact Airflow version before you commit.
What should a fixed-scope quote for this work include?
A fixed-scope quote should name the chosen auth manager, the identity provider and protocol, the list of Airflow roles and the group mapping for each, the environments in scope, and the Airflow version and upgrade state assumed. It should list the OAuth callback changes, the test plan for login, role access and API calls, the cutover steps and the rollback plan. It should also state who performs each task on your side, what is excluded, such as identity provider changes you own, and how changes to scope are priced. Most engagements are fixed-scope and agreed in writing before work starts, so ask for these items in the written scope.
Which Airflow version should we be on before switching?
Be on Airflow 3 before you build the new auth setup, because the auth routes, the API server and the auth manager settings all changed in that release. Airflow 2 reached end of life on April 22, 2026, and gets no fixes after that date, so a switch that keeps you on Airflow 2 leaves a security gap. The Airflow 3 upgrade guide requires being on Airflow 2.7 or later first. Confirm your current version and the upgrade path in the version life cycle page before you start the identity work.
How DeployOpen scopes an Airflow authentication change
An auth manager change starts with a written scope, not a configuration file. DeployOpen is a Chainscore Labs company, and most engagements are fixed-scope, so the scope document sets out which auth manager is chosen (FAB, Keycloak or AWS), which identity provider the Airflow instance will trust, how groups from that provider map to Airflow roles, and what the upgrade and cutover sequence looks like. Because Airflow allows only one auth manager at a time, set through the auth_manager option, that choice is recorded as a decision with its reasons before any build work begins. Deliverables and timelines are agreed in writing at the same stage, so the client knows what will be handed over and how it will be checked.
The scope also has to cover the parts that break in practice. Moving off the Simple auth manager changes how users sign in and how OAuth callback URLs are configured, because auth routes move under /auth in Airflow 3. Identity integration, role mapping, and the removal of simple_auth_manager_all_admins from any environment that serves real users are all work items with owners and acceptance checks. Verification is planned as a sequence: confirm that unauthenticated requests are refused, that each identity group lands in the intended role, that API tokens follow the same rules, and that the change is recorded in audit logs. Ask any provider to show this checklist in the written scope.
Ongoing work is handled separately from the fixed-scope build. Airflow releases, identity provider updates and changes in team membership all affect role mapping, so a retainer can cover periodic review, upgrade coordination and re-verification after changes. Before signing, confirm with the provider which Airflow and provider package versions the scope targets, who approves the production cutover, and how rollback is handled if the new login path fails. Ask for a written quote that follows from this scope rather than a generic estimate.
