Airflow RBAC – Role-Based Access Control

Airflow version 1.10.0 onward introduced Role-Based Access Control(RBAC) as part of their security landscape. RBAC is the quickest way to get around and secure airflow. It comes with pre-built roles which makes it easy to implement. Not stopping there you could add your own roles as well.

In addition, to securing various features of airflow web UI, RBAC can be used to secure access to DAGs as well. Though this feature is only available after 1.10.2. And as with any software, a few bugs popped. But this was fixed in the 1.10.7. There is an entry for a bug AIRFLOW-2694. In this blog entry, we will touch upon DAG level access as well.

The blog entry is divided into few parts

1. Enable RBAC
2. Create users using standard roles
3. Roles & permissions
4. Secure DAGs with RBAC

Needless to say, I am assuming you have a working airflow. If not, please head over to this link for help. Wrote a long time back but is still nice and useful.

Enable RBAC

To enable RBAC you need to modify airflow.cfg

To enable RBAC all you need to do is set rbac=true in airflow.cfg. See the screenshot below

Save the changes and goto the next step before starting airflow.

Note: If you start airflow you would see a login screen but there would be no user to login.

Create users using standard roles

When RBAC is enabled there are some default roles which are provided by default. Each role has a certain set of permissions.

• Admin – Has all the permissions. Has access to do everything.
• Viewer – Can only use the Airflow Web UI to see the status but cannot launch DAGs or change anything else. This is also Read-only access.
• Ops – Ability to modify the configuration
• Users – Able to perform DAG related tasks – marking DAGs/tasks as failed or successful. Able to launch DAGs etc
• Public – Role with permissions for unauthenticated users.

2.1 Using Command-line Interface

Airflow users can be created via the command-line interface. Using the following format

Let’s just understand what we did above

• “-r” is the role we want for the user
• “-u” is the username
• “-f” is the first name
• “-l” is the last name
• “-e” is the email id
• “-p” is the password

See Below

Let’s now navigate to our airflow url and we are now presented with a login screen.

Well now is the time to use your freshly minted username and password.

You will be presented with all the dags. Observer the additional menu item for Security which is added

2.2 Create users via Airflow Web UI

Like the admin user, other users can also be created via command line. I would prefer doing that when I am automating the deployment process. An easier way is to use Airflow Web UI.

It is quite simple and see below

Step 1 – Navigate to Security->List Users

Step 2 – Click on the + button

Step 3 – Fill in the details and press Save

Now we should be able to login using this user as well.

Roles and Permissions

3.1 Introduction

This is where things get a little more interesting. Back in the days when airflow was built, it used Flask-Admin for its admin security needs. But when 1.10 came along it was built using Flask-AppBuilder. Flask-AppBuilder has a security manager which formed the basis for Airflow’s RBAC security model.

Users are assigned roles and each role has a set of permissions. Permissions are given to various objects – Views, Menus and DAGs. Which secures the airflow. Pretty neat. But if it leaves you feeling a bit weird and asking a question – how is that? Read on!

3.2 Airflow View/Menus

All the Views, Menus and DAGs are listed on the Airflow Web UI on the following navigation path Security->View/Menus. If you go thru the list of view and menus you will observe it maps to every menu item, form which those menu items open.

It will open the following screen

If you scroll to the end – you will see our DAGs listed there as well. Which means we can secure our DAGs as well!!

It is easy to infer – Airflow allows to secure access to the above menu items and view. If you observe there is only a listing of these objects and nowhere to add new objects! That is because it is all based on Flask App-Builder Security model.

IMPORTANT: Read the permissions section on Flask AppBuilder Security.

Airflow, as you know, is built using Flask AppBuilder. Which means that it has its views built on ModelView class. That means Flask AppBuilder framework will be able to analyse your code and able to identify the Views.

But what about the operations that can be performed via those menu items and views!…well Read on!

3.3 Airflow Base Permissions

In addition to securing menu items and views. airflow also allows us to secure what operations are performed on the secured menu items. It does so by assigning permissions to a particular menu item or view. All these permissions are clubbed together under Security->Base Permissions.

As was the case with Airflow menu’s and views this is also a list. You cannot add to the list. That is also because it is all based on Flask App-Builder Security model.

IMPORTANT: Read the permissions section on Flask AppBuilder Security.

Airflow, as you know, is built using Flask AppBuilder. Which means that it has its views built on ModelView class. That means Flask AppBuilder framework will be able to analyse your code and able to identify the base permissions as well(in additions to the views earlier) – how cool is that! It does it for Views and Models both so you can have permissions for CRUD & REST operations automatically generated. If you haven’t read the Flask AppBuilder Security – I suggest you read it now! :).

3.4 Airflow Permissions on Views & Menus

Once Flask App-Builder has a list of views and their base permissions. It creates a combinations of views and the permissions identified. These combinations are available to be assigned to the roles. A list of all these combinations in airflow is available on Security->Permissions on Views and Menus

When you open the menu it should give you the following view. You can have a look around and get a good idea.

So, all of this already done for you. Let’s get around to the task at hand of assigning this to a new role.

3.5 Creating an Airflow role

Well, this is where we go and create a role. You may find it strange but there is no command line for creating roles!!. Well, folks at airflow have just not got around to it. So, we have to use the Airflow Web UI to create them.

Even though the menu says list roles. You can also create roles. Press the “+” icon. By default, when you create a role – airflow adds a few menu/view and base permissions combinations by default. All that airflow does is that we are able to see the menu items though we do not get access to any functionality.

3.5.1 – Example – create a role – “test_role”

Let’s create a role which is able to only list Airflow variables and not do anything else. To achieve this objective – the role should have access to the following

• Access to Admin menu
• Access to Variables menu inside the admin menu
• Ability to list variables

Save the role

A role is added to the list of available roles at the bottom

If you refresh the page you would find that airflow has added additional combinations of view/menu and base permissions.

3.5.2 Example – Assign “test_role” to “test_user”

Now that our role – “test_role” has been created let’s assign it to a user. Goto Security->List Users

It’s time to login and check if it all works!!!

Open a new browser window and goto the airflow landing link

Only the Admin->Variables is available. No DAGs are visible and most menu options are not visible.

Click of Admin->Variables the variables are listed but it is not possible to edit them.

Let’s now add some additional configuration to the test_role so that it can also edit the variable but still cannot add new ones.

Now if you login as test_user and goto Admin->Variables you would see the edit button has been enabled.

Press the edit button to edit the variable.

Secure DAGs with RBAC

If you have made it till here – Well done! It is quite similar to what we have done in the previous section.

Let’s take an example – we want any user using the “test_role” to be able to view the DAG hello_world2 but not be able to do anything else with it.

We go back to our test_role and edit it and add the following

Save the role and login via the “test_user“. You would be able to see just one dag which is hello_world2. See below

You can similarly add additional configuration so that all users with test_role are able to trigger the various functions of the hello_world2 DAG.

This brings us to the end of fairly long post and if you have gone through it all – well done. I hope this post is useful to you as it has been to me. Till next time!