Airflow v3 user creation command fails

[markhc]

Apache Airflow version

3.0.1

If "Other Airflow 2 version" selected, which one?

No response

What happened?

Unsure if this is my mistake, but the createUserJob fails on Kubernetes using the Helm chart.

Here's the output of the airflow users command that displays the same error as the createUserJob.

airflow@airflow-api-server-6865b4769f-cvl2c:/opt/airflow$ airflow users
Usage: airflow [-h] GROUP_OR_COMMAND ...

Positional Arguments:
  GROUP_OR_COMMAND

    Groups
      assets            Manage assets
      backfill          Manage backfills
      config            View configuration
      connections       Manage connections
      dags              Manage DAGs
      db                Database operations
      jobs              Manage jobs
      kubernetes        Tools to help run the KubernetesExecutor
      pools             Manage pools
      providers         Display providers
      tasks             Manage tasks
      variables         Manage variables

    Commands:
      api-server        Start an Airflow API server instance
      cheat-sheet       Display cheat sheet
      dag-processor     Start a dag processor instance
      info              Show information about current Airflow and environment
      kerberos          Start a kerberos ticket renewer
      plugins           Dump information about loaded plugins
      rotate-fernet-key
                        Rotate encrypted connection credentials and variables
      scheduler         Start a scheduler instance
      standalone        Run an all-in-one copy of Airflow
      triggerer         Start a triggerer instance
      version           Show the version

Options:
  -h, --help            show this help message and exit

airflow command error: argument GROUP_OR_COMMAND: invalid choice: 'users' (choose from api-server, assets, backfill, cheat-sheet, config, connections, dag-processor, dags, db, info, jobs, kerberos, kubernetes, plugins, p
ools, providers, rotate-fernet-key, scheduler, standalone, tasks, triggerer, variables, version), see help above.

What you think should happen instead?

No response

How to reproduce

Run airflow users -h on v3.0.1 Airflow Docker image.

Operating System

Kubernetes

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

Deployment on GKE using ArgoCD.

Anything else?

No response

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[tirkarthi]

Do you have Airflow fab provider installed?

https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/cli-ref.html

https://github.com/apache/airflow/blob/main/providers/fab/src/airflow/providers/fab/auth_manager/cli_commands/user_command.py

[markhc]

This is a standard deploy using the provided helm chart. I have not modified any settings related to providers, so if it doesn't come pre-installed I do not have it.

My point is that, in my opinion, a standard installation should work out of the box. As it stands I cannot login to the deployed Airflow instance as no default user has been created.

[markhc]

Also, even after installing apache-airflow-providers-fab the error persists

airflow@airflow-api-server-6865b4769f-cvl2c:/opt/airflow$ pip freeze | grep fab
apache-airflow-providers-fab==2.0.2

airflow@airflow-api-server-6865b4769f-cvl2c:/opt/airflow$ airflow users create
Usage: airflow [-h] GROUP_OR_COMMAND ...

Positional Arguments:
  GROUP_OR_COMMAND

[...] omitted for brevity

Options:
  -h, --help            show this help message and exit

airflow command error: argument GROUP_OR_COMMAND: invalid choice: 'users' (choose from api-server, assets, backfill, cheat-sheet, config, connections, dag-processor, dags, db, info, jobs, kerberos, kubernetes, plugins, p
ools, providers, rotate-fernet-key, scheduler, standalone, tasks, triggerer, variables, version), see help above.

[potiuk]

You need to have FabAuthManager conifgured. The users command is part of the Fab Auth Manaager https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/cli-ref.html.

"Standard" installation now uses SimpleAuthManeager https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/auth-manager/simple/index.html

[markhc]

You need to have FabAuthManager conifgured. The users command is part of the Fab Auth Manaager https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/cli-ref.html.

"Standard" installation now uses SimpleAuthManeager https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/auth-manager/simple/index.html

Do you have an example on how to configure it then? Because I have the package installed and I've set auth_manager = airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager in the [core] section of the config file but both airflow users create and flask fab create-user still fail.

[potiuk]

You need to have FabAuthManager conifgured. The users command is part of the Fab Auth Manaager https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/cli-ref.html. "Standard" installation now uses SimpleAuthManeager https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/auth-manager/simple/index.html

Do you have an example on how to configure it then? Because I have the package installed and I've set auth_manager = airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager in the [core] section of the config file but both airflow users create and flask fab create-user still fail.

No idea - works for me when I just set it - i guess some settings on your side are not applied in the container:

[markhc]

Somehow reinstalling fixed it. Really not sure what was wrong in my first install. The only thing I changed was setting FAB as the auth manager in the Helm chart from the beginning (my first install was using SimpleAuth at first).

Thanks!

[mrbungie]

It also failed for me when using the helm chart, in fact, it does not show up in airflow subcommands but fab is installed and used for Oauth against Azure. Very weird.

[potiuk]

It also failed for me when using the helm chart, in fact, it does not show up in airflow subcommands but fab is installed and used for Oauth against Azure. Very weird.

I think it depends on how you are running the airflow command and whether the container you are running it in has the FAB provider installed and FAB Auth manager configured. Can you check it ?

[mrbungie]

First of all, and as always thank you so much for Apache Airflow :), I've depended on it for years for many projects.

And yes, as far as I can tell we do have it installed. Some "evidence" that may help, short of showing the running system.

1. I'm using a custom docker image (but based on apache/airflow:3.0.0-python3.12) that includes this in its requirements: apache-airflow-providers-fab==2.0.1. This is a gist with its definition and related files: https://gist.github.com/mrbungie/ab8e2a2104e56c7d6dc8872d01d44f9a
2. I'm setting the following relevant values in my helm chart: https://gist.github.com/mrbungie/eaae9aed11d04b04d960376788d3e91e (here im showing it with webserver.defaultUser = false, but when I set it to true, the createUser fails)
3. We implemented a webserver_config.py (shown in [1] gist integrated with EntraID). And it works, so FAB is working.

When I get into most containers, they do have the users subcommand:

But when checking the create-user container (after setting createUser to true), it fails.

I'm pretty sure it has to do with the fact that the env vars overriding Auth are not reaching the createUser container. create-user envvars:

Meanwhile other containers (like api-server)

I guess that means that that setting (i.e. airflow.core.auth_manager / AIRFLOW__CORE__AUTH_MANAGER) should be set exclusively via airflow.cfg, but I think docs should be clearer about that.

If that's not the hoped behaviour, I would guess AIRFLOW__CORE__AUTH_MANAGER, if set, should be propagated down into the create-user container (after all, if its going to run create-user in Airflow 3, it should have that set to FAB or it is always going to fail). Maybe the create-user container should check if FAB is on (via env var + airflow.cfg), and if not, it should just continue gracefully and maybe logging that so users are advised to set createUser = false if they are just using Simple Auth.

If anything I'm saying makes sense, I can make a PR fixing this in some direction you propose.

More info: Helm chart commit SHA256: https://github.com/apache/airflow/commit/3bd9746d5c30d47fec1e50cc95a3b83add1ee3e8

[potiuk]

OK. So it means that createUserJob template needs to be fixed. I marked it for next chart version and as good first issue. Anyone is invited to fix it.

[potiuk]

If anything I'm saying makes sense, I can make a PR fixing this in some direction you propose.

Makes absolutely sense. Thanks for all those invstigations @mrbungie ! and Fix would be really nice!

[Iphykay]

From version>=3.0.0, no subcommand 'users'.

You would have to use airflow standalone, which also gets an error

[GrumpyCat51]

@mrbungie may I ask how you added the AIRFLOW__CORE__AUTH_MANAGER env variable? Did you add it through the extraEnv:/extraEnvFrom, or through the config.core: section (or any other way)?

[Brunda10]

I'm looking into this issue and would like to contribute if it's still unresolved.

[Brunda10]

This happens because Airflow 3.x uses SimpleAuthManager as the default auth manager, which does not support the airflow users CLI command.

Even if you try to use FabAuthManager, the system may override it back to SimpleAuthManager—especially in dev setups (like Breeze or standalone mode), where the environment is explicitly set or forced during container startup.

To fix this and re-enable the users CLI, you need to explicitly set the following environment variable:

export AIRFLOW__CORE__AUTH_MANAGER=airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager

and restarting the breeze environment

[Brunda10]

Changed default Breeze auth_manager to FabAuthManager (from simple_auth). Tested inside Kubernetes container shell: able to create users and verify FAB auth setup via CLI and UI.

[Brunda10]

---

📝 Overview of the Issue

By default, the Breeze environment launches Airflow with SimpleAuthManager, which lacks support for role-based access control (RBAC), user management, and the full security UI. This makes it difficult for developers to test features that require a realistic authentication and authorization setup — for example, creating users via UI or CLI, assigning roles, or validating permissions.

airflow@airflow-api-server-6865b4769f-cvl2c:/opt/airflow$ airflow users create
Usage: airflow [-h] GROUP_OR_COMMAND ...

Positional Arguments:
  GROUP_OR_COMMAND

[...] omitted for brevity

Options:
  -h, --help            show this help message and exit

airflow command error: argument GROUP_OR_COMMAND: invalid choice: 'users' (choose from api-server, assets, backfill, cheat-sheet, config, connections, dag-processor, dags, db, info, jobs, kerberos, kubernetes, plugins, p
ools, providers, rotate-fernet-key, scheduler, standalone, tasks, triggerer, variables, version), see help above.

---

🔧 How the Issue Was Fixed

I updated the Breeze CLI logic and Airflow standalone logic to default to FabAuthManager instead of SimpleAuthManager.

1. developer_commands.py

File: dev/breeze/src/airflow_breeze/commands/developer_commands.py

Change:

# Before:
default=ALLOWED_AUTH_MANAGERS[0],  # SIMPLE_AUTH_MANAGER

# After:
default=ALLOWED_AUTH_MANAGERS[1],  # FAB_AUTH_MANAGER

This ensures that breeze start-airflow launches Airflow with FAB Auth by default.

2. standalone_command.py

File: airflow/cli/commands/standalone_command.py

I updated the auth_manager used in standalone mode to also default to FabAuthManager.

---

🧪 Testing

I tested this setup in the following environments:

• ✅ Breeze bash terminal
• ✅ Kubernetes bash terminal

In both cases, I was able to:

• Login through FAB-authenticated UI
• Create users via CLI and UI
• View the Security tab and manage roles/permissions

[ashb]

@Brunda10 AI generated responses are not helpful.

[akshayvijayjain]

Dear @ashb ,

I see your comment mentioning https://github.com/apache/airflow/pull/53854#issuecomment-3133968783 this issue may fall into won't fix;

So you may un-spam @Brunda10 ; Currently her comment is hidden as she is marked as spam;

She is working on this issue since 5 days full time at ZemosoLabs; reproducing it; tweaking code;

We have 6 more developers working this way to contribute to Apache airflow and hone skill in python and contributing to open source. last year we did this with appsmith project https://github.com/appsmithorg/appsmith/ contributing to backend and frontend

She has certainly made use of AI which is expected as per me, to understand things in more context.

I have heard her explain the approach; i.e. simple auth manager is passed as default argument, so changing it to fab auth manager should fix the issue; if it is deliberate choice to use simple auth manager; it cannot be logically known easily;

we appreciate, you are careful about spam; If you any suggestion for us, it is most welcome.

---

She has also noted a related issue https://github.com/apache/airflow/issues/53882

[ashb]

Think about what the a comment adds to the issue - does the LLM output saying how you fixed it in a PR add anything to the issue?

I'm sorry for marking it as spam , but we get a lot of such LLM generated content, which are always long and it takes a lot of the maintainer time to read, and understand, when a much shorter and more succinct post is better. Essentially by having the full LLM content you are putting the onus on us as already-time-stretched-maintainers to do more work.

So I don't mind LLM per-se, just please be thoughtful of what invisible work you might be putting on maintainers.

[potiuk]

So I don't mind LLM per-se, just please be thoughtful of what invisible work you might be putting on maintainers.

I am here very much with @ashb - adding a lot of LLM generated text describing the issue in a chatty way is generally noise. We have to - as maintainers - read that noise in order to decide what to do - and it's not helpful in anything.

So do not treat it personally @Brunda10 -> just be careful what kind of information you post in the issue - and especially be very careful about amount of non-helpful and not-adding value generated "mumbling" the AI agents love to produce.

[Brunda10]

Got it, thanks for pointing that out . I’ll keep my future comments focused and avoid unnecessary verbosity.

[samir-ibbou]

Hi, I have a error message when I log in with FAB auth manager. I don't know if you can help me.

[potiuk]

I have a error message when I log in with FAB auth manager.

Not really. Maybe someone will be able to help you if you open discsusion and try to explain your configuration logs etc. but helping with a screenshot of "not authorized" is not actionable for help.

[prakharcode]

I am also currently facing this bug, while trying to deploy aiflow 3.0.2 and using simple.auth.manager in the CI environment. While I understand that simple auth is not made to be something to be deployed in production but it is a good (fast) way to go with in CI and alike.

@mrbungie summarized quite well here:

If that's not the hoped behaviour, I would guess AIRFLOW__CORE__AUTH_MANAGER, if set, should be propagated down into the create-user container (after all, if its going to run create-user in Airflow 3, it should have that set to FAB or it is always going to fail). Maybe the create-user container should check if FAB is on (via env var + airflow.cfg), and if not, it should just continue gracefully and maybe logging that so users are advised to set createUser = false if they are just using Simple Auth.

giving an option in the helm chart to do enable: false would be nice, then the onus of disable and enabling the service is on the user.

If this makes sense, I can contribute to include this in the chart. I see the issue is already assigned to @Brunda10 but if they are not working I can take it up or they can continue with this direction if maintainers agree.

[Brunda10]

Hi @prakharcode , I was previously assigned but I’ve been working on other issues. If you’d like to work on it, please move forward .

[prakharcode]

cool, let me know if adding to helm chart makes sense @ashb @potiuk then I can take it.

[ashb]

We're generally moving away from assigning issues for precisely this issue. It's now unassigned (and will remain so), so feel free to work on a PR @prakharcode

[prakharcode]

I just had a look again, and within the webserver Values in the defaultUser value you can put enabled: false this solves the issue of having a failed container on a helm release of airflow.

  webserver:
    enabled: false
    defaultUser:
      enabled: false

What bothers me is that these values are used from webserver but not from apiServer or directly giving a enabled: false within the createUser job Values.

For now I will add an enabled parameter in the values with the chart taking an and condition on both job webserver.defaultUser.enabled and createUserJob.enabled