MWAA(Airflow)のユーザー・権限管理効率化に敗北したが最近のアプデでできた話

背景

Airflowではこういうケースを想定していないのかもしれないが、今回のユースケースは以下である。

• AWSのアカウント上には複数のプロジェクトが存在する。
• コストの都合上MWAAのリソースは一つのみ。(プロジェクト間で共通とする。)
• プロジェクト間で、DAGの中身などが見れてはいけない。

まとめると、一つの MWAAリソースの中で、複数のプロジェクトを管理したいということである。

Airflow の権限管理の話

ここではAirflow(≠ MWAA)の話をする。
Airflow は、ユーザーにロール(権限を付与したもの)をアタッチするシンプルな仕組みである。
がこのroleにアタッチする権限が結構やっかいである。
以下の様に、個別のdagの閲覧、編集、削除の権限を付けるためにはdagが既に存在している必要があり、またワイルドカードなどは使えないため。作るたび権限付与をしなければいけない。

付与の仕組みとしては、

• ブラウザから手動で行う
• Airflow REST API から行う。

なため、考えつくのは、dag 作成 (dag フォルダにファイルが作成)たびに、イベントトリガーでapi をたたけば良いと思うのであったが・・・

MWAA での権限管理の話

結論から申し上げると、MWAAでは Airflow REST APIはセキュリティ上の理由から禁止されているため使うことができません。
そのかわり aws mwaa コマンドを使うことで、代外的に操作することができます。が・・・
create role とか add permission とかないやんけ！と思っていたところ、最近のアップデートでadd permissionのみできるようになっていました！！！

最終的にどうするか

• ロールを作成する。(ロールを作成後、MWAAのリソースを再起動しないと、認識されない・・・)
• ユーザーを作成、ロールをアタッチ。(手動)
• ロールに対して、add-permission を実行し逐次権限を追加する。(イベントトリガーで実行、path でどのグループ化をはんだんできる等の改修は必要)

その他

まあ、ぶっちゃけ MWAA のリソース分けられない限り、実行ロールを変えられないので (今回は書いていないけど、疑似的にmwaaの実行ロール → プロジェクトごとの実行ロールに継承させて、申し訳程度の安全性を上げているものの) 、真面目に考えていくとどうしようもないのかもしれない。

cloud composer は最初からこれができているという噂、😢