AIP-84 Add GET User Permissions endpoint

[bbovenzi]

Description

We are adding Auth and Permissions to the API. It would be great for the UI to be aware of permissions to proactively disable actions or views without the user seeing errors everywhere.

Ideally, this could be a ui/permissions endpoint that lists each entity and what CRUD actions the user can perform. If the action is missing, the UI will assume the user can't perform it.

[
  asset: ['GET', 'POST', 'PATCH', 'DELETE'],
  backfill: ...,
  connection: ...,
  dag_run: ...,
  dag: ...,
  task_instance: ...,
]

I don't know if the entities match 1-to-1 the API docs at http://localhost:29091/docs#/ but that would be the easiest I think.

Use case/motivation

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

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

[bbovenzi]

cc: @jedcunningham @pierrejeambrun @vincbeck

[jedcunningham]

It's a little tricky - the auth manager doesn't even define a "string" for each entity... I guess the string in the method name, e.g. is_authorized_{x} would work though. That's easy enough.

Another wrinkle, the auth manager methods are designed around authz for a specific entity too. e.g. "a specific" dag, not "dags". So it's possible for triggering DAG a to be okay, but not DAG b. If we did go from entity level (dags) to specific entities (a dag), well, we can't just load it once during UI startup either as that can change over time. Hmm.

(Don't mean to just bring up problems, but want to articulate the challenges I see so we can find the right balanced answer)

[bbovenzi]

Ok, so the UI will assume a user can access any general page and if they don't have "read" permissions the list may be truncated or just empty. Is that right?

So would some entity id (dag_id, asset.id, etc) lookup work? I think that would work well for dag and asset details pages. But for our custom list pages, we might need to add permissions to the existing query. Ex: get /ui/dags could include if each dag can be triggered.

[jedcunningham]

Ok, so the UI will assume a user can access any general page and if they don't have "read" permissions the list may be truncated or just empty. Is that right?

Idk, feels not great to show variables anything, for example, if you don't have access to do anything with variables at all.

The menu perms we need to expose in the auth manager will probably help here though, meaning if someone did land on the page via direct link or something, "empty" would be fine.

So would some entity id (dag_id, asset.id, etc) lookup work? I think that would work well for dag and asset details pages. But for our custom list pages, we might need to add permissions to the existing query. Ex: get /ui/dags could include if each dag can be triggered.

We could add the ability to do that, yes. Doing it by entity id, or list of entity ids, is probably easier than doing something en mass like in the description.

And baking those into certain responses so there isnt another round trip makes sense.

[bbovenzi]

Idk, feels not great to show variables anything, for example, if you don't have access to do anything with variables at all.

The menu perms we need to expose in the auth manager will probably help here though, meaning if someone did land on the page via direct link or something, "empty" would be fine.

I agree. I am just trying to understand what the auth manager can do. It would be ideal to adjust the NavBar to hide things like connections or variables

I think we also just need to make sure our custom endpoints check the read permissions per entity so that our dashboard stats are only for the dags/assets you have access to.

[vincbeck]

I think we should create a new method in the auth manager that give you this information. A very similar method we used to have: filter_menu_items, I needed to delete this method because it relied on Flask but we should create a new one. Something like this:

def filter_menu_items(items: list[str]) -> list[str]:
  ... 

The function takes a list of menu items (which would be the name of the menu: "Variables", "Connections") and returns the same list but after having filtered out menu items the user do not have access to. This is the best option we have I think. If we do that, we need to define the exhaustive list of menu items (with an enum or something similar)

[vincbeck]

If agreed, @pierrejeambrun or @bbovenzi could you create such list and then from there I can do the rest?

[bbovenzi]

  dags
  dag runs
  task instances
  assets
  asset events
  variables
  pools
  providers
  plugins
  connections
  xcoms
  audit log

These are all our main pages except for the dashboard.
But I would definitely want to check actions on a specific asset, dag, dag run or task instance. For the list pages we should add those permissions to ui/dags and probably create a ui/ wrapper for our other list endpoints so we can check when to show actions in a table view