Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add declarative configuration to define custom roles #38347

Open
2 tasks done
ketozhang opened this issue Mar 20, 2024 · 6 comments
Open
2 tasks done

Add declarative configuration to define custom roles #38347

ketozhang opened this issue Mar 20, 2024 · 6 comments

Comments

@ketozhang
Copy link
Contributor

Description

Add declarative configuration to define custom roles in either airflow.cfg or webserver_config.py.

Use case/motivation

Currently the only way to define custom roles is through the CLI or UI. This isn't ideal for those deploying configuration through a repository (e.g., GitOps).

It seems like this feature is already possible with webserver_config.py, however not documented here. If so, I will change the request...
https://airflow.apache.org/docs/apache-airflow/stable/security/webserver.html

Related issues

No response

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

@ketozhang ketozhang added kind:feature Feature Requests needs-triage label for new issues that we didn't triage yet labels Mar 20, 2024
@potiuk
Copy link
Member

potiuk commented Mar 22, 2024

Sure. If you have a good idea how to do it in a robust way - proposing a solution, especially one that will not overwrite existing DB and will allow to both declaratively upload roles from a source and manually modify them, and keep those local modificiattions - PRs are most welcome.

Just make sure when you submit the PR to propose a solution for this conundrum where you have both manually modifiable data and uploadable from the externally depoyable sources in declarative way. So far all the efforts failed on that step, but maybe you will be able to propose something.

BTW. once you find a solution, also similar thing should be done from connections, users and variables - those suffer from the same issue and if you find and get approval to solve it for roles, applying similar approach for the others is a natural next step.

@ketozhang
Copy link
Contributor Author

Thanks and yep, it's a classic problem most devops folks have to deal with. It's heavily dependent if you want to lock down configs post-deploy and if DB should be overwritten during a redeploy.

What's currently being done for connections and variables to solve that issue? They both already have declarative equivalents.

So far all the efforts failed on that step

How have they failed?

@potiuk
Copy link
Member

potiuk commented Mar 22, 2024

How have they failed?

To solve all the edge cases and the fact that users can modify the DB after it has been created and how to consistently mantain source of the truth.t But maybe your proposal will fix it. Looking forward to it.

@potiuk
Copy link
Member

potiuk commented Mar 22, 2024

What's currently being done for connections and variables to solve that issue? They both already have declarative equivalents.

No - they don't - same problem. When you allow to edit data over the UI and want to also upload it at the deployment time, you need to solve the problem of data being modified both manually and through declarative sources at deplpyment time

@shahar1
Copy link
Contributor

shahar1 commented Jul 13, 2024

@ketozhang Would you still like to work on this issue?

@shahar1 shahar1 added area:core area:webserver Webserver related Issues provider:fab area:providers and removed needs-triage label for new issues that we didn't triage yet area:core area:webserver Webserver related Issues labels Jul 13, 2024
@ketozhang
Copy link
Contributor Author

I don't have a implementation proposal yet. Someone else can take it if they've got ideas.


Well I do have one idea... env vars. Airflow does allow many configs to be set/overridden with env vars (I guess it's a simple if env var exist, don't use DB values).

The value of the role env var would be JSON string. Here's an example without proper formatting...

{
  "roles": {
    "PythonTester": [
      {
        "permission": "ACTION_CAN_EDIT",
        "resource": "RESOURCE_DAG"
      }
    ]
  }
}

A few caveats:

  • You cannot modify the roles of the same name in the UI and env-vars. Precedence goes to env-vars. Different name is OK.
    • UI should show env-vars defined roles to be grayed-out (i.e., read-only)
  • You cannot use env-vars to define custom roles with DAG-level permissions. Instead, this is declaratively set by the DAG file (DAG(access_control={...}))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants