Cloud Composer 1 はメンテナンス後モードです。Google は、Airflow の新しいバージョン、バグの修正、セキュリティアップデートなど、Cloud Composer 1 への今後のアップデートはリリースしません。 Cloud Composer 2 への移行の計画をおすすめします。

Airflow UI のアクセス制御の使用

Cloud Composer 1 | Cloud Composer 2

このページでは、Airflow UI と DAG UI に対するアクセス制御のさまざまなメカニズムについて説明します。IAM によって提供されるアクセス制御に加えて、これらのメカニズムを使用して、お使いの環境の Airflow UI と DAG UI でユーザーを分離できます。

Cloud Composer の Airflow UI アクセス制御の概要

Airflow UI と DAG UI へのアクセスと、それらの UI のデータとオペレーションの公開設定は、Cloud Composer では次の 2 つのレベルで制御されます。

Cloud Composer での Airflow UI と DAG UI へのアクセスは IAM によって制御されます。

プロジェクトで Cloud Composer 環境を表示できるロールがアカウントに付与されていない場合、Airflow UI と DAG UI は使用できません。

IAM は、Airflow UI や DAG UI で追加の詳細な権限制御を行うことはありません。
Apache Airflow アクセス制御モデルを使用すると、ユーザーロールに基づいて Airflow UI と DAG UI の可視性を低減できます。

Apache Airflow アクセス制御は Airflow の機能であり、IAM とは異なる独自のユーザー、ロール、権限のモデルを持っています。

Apache Airflow アクセス制御は、リソースベースの権限を使用します。特定の Airflow のロールを持つ Airflow ユーザーはすべて、このロールの権限を取得します。たとえば、can delete on Connections 権限を持つロールを付与された Airflow ユーザーは、Airflow UI の [接続] ページで接続を削除できます。

個々の DAG に DAG レベルの権限を割り当てることもできます。たとえば、特定の Airflow ロールを持つユーザーだけが Airflow UI で特定の DAG を表示できるように設定可能です。Cloud Composer では、環境のバケット内の DAG ファイルが配置されているサブフォルダに基づいて、DAG レベルの権限を自動的に割り当てることができます。

Workforce Identity 連携を使って外部 ID アクセスを設定するには、外部 ID に IAM ロールを付与するセクションにあるように、まず、IAM で環境へのアクセス権を付与します。その後、通常どおり Airflow UI アクセス制御を使用できます。外部 ID の Airflow ユーザーは、メールアドレスの代わりにプリンシパル ID を使用し、Google アカウントとは異なるユーザーレコードフィールドに異なる値を入力できます。

始める前に

フォルダごとのロール登録は Cloud Composer 2.0.16 以降のバージョンで使用できます。

Airflow のロールとアクセス制御設定を管理する

管理者のロール（または同等のロール）を持つユーザーは、Airflow UI でアクセス制御の設定を表示および変更できます。

Airflow UI では、[セキュリティ] メニューからアクセス制御設定を構成できます。Airflow アクセス制御モデル、使用可能な権限、デフォルトロールの詳細については、Airflow UI のアクセス制御のドキュメントをご覧ください。

Airflow は独自のユーザーリストを保持します。管理者のロール（または同等のロール）を持つユーザーは、環境の Airflow UI を開いて、Airflow に登録されたユーザーの一覧を表示できます。このリストには、次のセクションで説明するように、管理者が手動で事前登録したユーザーも含まれます。

Airflow UI でユーザーを登録する

Cloud Composer 環境の Airflow UI を初めて開いた新しいユーザーは、自動的に登録されます。

登録時に、[webserver]rbac_user_registration_role Airflow の構成オプションで指定されたロールがユーザーに付与されます。新規登録ユーザーのロールを管理するには、この　Airflow 構成オプションを別の値でオーバーライドします。

指定しない場合、Airflow 2 を使用する環境でデフォルトの登録のロールは Op になります。

Airflow UI の基本ロールの構成を作成する場合、次の手順をおすすめします。

環境管理者は、新しく作成された環境の Airflow UI を開きます。
管理者アカウントに Admin ロールを付与します。Airflow 2 を使用する環境での新しいアカウントのデフォルトのロールは Op です。Admin ロールを割り当てるには、gcloud を使用して次の Airflow CLI コマンドを実行します。
```
  gcloud composer environments run ENVIRONMENT_NAME \
    --location LOCATION \
    users add-role -- -e USER_EMAIL -r Admin
```
次のように置き換えます。
- ENVIRONMENT_NAME を環境の名前にする。
- LOCATION は、環境が配置されているリージョン。
- USER_EMAIL は、ユーザーアカウントのメールアドレス。
管理者は、他のユーザーに Admin ロールを割り当てるなど、新しいユーザーのアクセス制御を構成できます。

ユーザーを事前登録する

ユーザーは、（メールアドレスではなく）Google ユーザーアカウントの数値 ID がユーザー名として自動的に登録されます。また、手動でユーザーを登録し、ユーザー名のフィールドをユーザーのメインのメールアドレスに設定したユーザーレコードを追加して、ユーザーにロールを割り当てることもできます。事前登録ユーザーレコードと一致するメールアドレスを持つユーザーが初めて Airflow UI にログインすると、そのユーザー名は現在メールアドレスで識別されている（最初のログイン時に）ユーザー ID に置き換えられます。Google ID（メールアドレス）とユーザーアカウント（ユーザー ID）の関係は固定されていません。Google グループは事前登録できません。

ユーザーを事前登録するには、Airflow UI を使用するか、Google Cloud CLI から Airflow CLI コマンドを実行します。

Google Cloud CLI を使用してカスタムロールを持つユーザーを事前登録するには、次の Airflow CLI コマンドを実行します。

gcloud composer environments run ENVIRONMENT_NAME \
  --location LOCATION \
  users create -- \
  -r ROLE \
  -e USER_EMAIL \
  -u USER_EMAIL \
  -f FIRST_NAME \
  -l LAST_NAME \
  --use-random-password # The password value is required, but is not used

以下を置き換えます。

ENVIRONMENT_NAME: 環境の名前。
LOCATION: 環境が配置されているリージョン
ROLE: ユーザーの Airflow ロール（例: Op）
USER_EMAIL: ユーザーのメールアドレス
FIRST_NAME と LAST_NAME: ユーザーの名と姓

例:

gcloud composer environments run example-environment \
  --location us-central1 \
  users create -- \
  -r Op \
  -e "example-user@example.com" \
  -u "example-user@example.com" \
  -f "Name" \
  -l "Surname" \
  --use-random-password

ユーザーの削除

ユーザーを Airflow UI から削除しても、そのユーザーが Airflow UI に次回アクセスしたときに自動的に登録されるため、ユーザーのアクセス権は取り消されません。Airflow UI 全体へのアクセス権を取り消すには、プロジェクトの許可ポリシーから composer.environments.get 権限を削除します。

ユーザーのロールを「パブリック」に変更することで、ユーザーの登録を維持しつつ、Airflow UI のすべての権限を削除することもできます。

DAG レベルの権限を自動的に構成する

フォルダごとのロール登録機能では、/dags フォルダ内の各サブフォルダごとにカスタム Airflow ロールが自動的に作成され、このロールにすべての DAG レベルのアクセス権が、ソースファイルがそれぞれのサブフォルダに保存されているすべての DAG に付与されます。これにより、カスタム Airflow ロールと DAG へのアクセスの管理が合理化されます。

フォルダ単位のロール登録の仕組み

フォルダ単位のロール登録は、ロールとその DAG レベルの権限を構成する自動化された方法です。そのため、DAG レベルの権限を付与するほかの Airflow メカニズムとの競合が発生する可能性があります。

DAG 権限をロールに手動で割り当てる。
DAG 内の access_control プロパティを使用して DAG をロールに割り当てる。

このような競合を防ぐため、フォルダ単位のロール登録を有効にすると、これらのメカニズムの動作も変更されます。

Airflow 2 では:

DAG のソースコードで定義されている access_control プロパティを使用して、DAG へのアクセス権をロールに付与できます。
（Airflow UI または gcloud CLI を介して）手動で DAG 権限を付与すると、競合が発生することがあります。たとえば、DAG レベルの権限を手動でフォルダ単位のロールに付与すると、DAG プロセッサが DAG を同期する際にこれらの権限を削除または上書きできます。DAG 権限は手動で付与しないことをおすすめします。
ロールには、フォルダ単位のロール登録によって登録され、DAG の access_control プロパティで定義された DAG アクセス権限の組み合わせが含まれます。

最上位の /dags フォルダにある DAG は、フォルダごとのロールに自動的に割り当てられません。フォルダごとのロールでアクセスすることはできません。管理者、Op、ユーザーなど、他の権限を持つロールは、Airflow UI と DAG UI を通じてアクセスできます。

組み込みの Airflow ロールおよび Cloud Composer によって作成されたロールと一致する名前の DAG をサブフォルダにアップロードする場合、これらのサブフォルダ内の DAG の権限は引き続きこれらのロールに割り当てられます。たとえば、DAG を /dags/Admin フォルダにアップロードすると、この DAG に対する権限が管理者ロールに付与されます。組み込みの Airflow ロールには、管理者、Op、ユーザー、閲覧者、パブリックが含まれます。Cloud Composer では、フォルダ単位のロール登録機能が有効になった後に、NoDags と UserNoDags が作成されます。

Airflow スケジューラで DAG を処理する際に、Airflow はフォルダ単位のロール登録を行います。環境内の DAG が 100 を超えると、DAG 解析時間が増加することがあります。この場合は、スケジューラにより多くのメモリと CPU を使用することをおすすめします。[scheduler]parsing_processes Airflow 構成オプションの値を増やすこともできます。

DAG をフォルダごとのロールに自動割り当てる

DAG をフォルダごとのロールに自動的に割り当てるには:

次の Airflow 構成オプションをオーバーライドします。

セクションキー値

webserver rbac_autoregister_per_folder_roles True
新しいユーザー登録ロールを、DAG にアクセスできないロールに変更します。このようにして、管理者が特定の DAG に対する権限を持つロールをアカウントに割り当てるまで、新規ユーザーは DAG にはアクセスできません。

UserNoDags は、フォルダ単位のロール登録機能が有効になっている場合にのみ Cloud Composer によって作成されるロールです。これはユーザーロールと同等ですが、DAG へのアクセス権はありません。

次の Airflow 構成オプションをオーバーライドします。

セクションキー値

webserver rbac_user_registration_role UserNoDags
ユーザーが Airflow に登録されていることを確認します。
次のいずれかの方法でユーザーにロールを割り当てます。
- Airflow が DAG サブフォルダに基づいて自動的にロールを作成し、ユーザーをこれらのロールに割り当てます。
- DAG サブフォルダ用の空のロールを、サブフォルダの名前と一致するロール名で事前に作成して、これらのロールにユーザーを割り当てます。たとえば、/dags/CustomFolder フォルダの場合は、CustomFolder という名前のロールを作成します。
注意: DAG を使用してフォルダを作成したユーザーは、対応するフォルダごとのロールを自動的に取得しません。たとえば、ユーザーが CustomFolder という名前のサブフォルダを作成した場合、そのユーザーのアカウントには CustomFolder ロールが付与されません。管理者は Airflow UI でこのロールを付与する必要があります。
ユーザーに割り当てられたロールと一致する名前の DAG をサブフォルダにアップロードします。これらのサブフォルダは、環境のバケットの /dags フォルダ内に配置する必要があります。Airflow では、このようなサブフォルダ内の DAG に権限が追加され、対応するロールを持つユーザーだけが Airflow UI と DAG UI を介してアクセスできるようになります。

セクション	キー	値
`webserver`	`rbac_autoregister_per_folder_roles`	`True`

セクション	キー	値
`webserver`	`rbac_user_registration_role`	`UserNoDags`

DAG レベルの権限を手動で構成する

カスタムロールの DAG レベルの権限を構成して、特定のユーザーグループに表示される DAG を指定できます。

Airflow UI で DAG レベルの権限を構成するには:

DAG をグループ化するための空のロールを管理者が作成します。
管理者がユーザーを適切なロールに割り当てます。
管理者またはユーザーが DAG をロールに割り当てます。
Airflow UI では、グループに割り当てられた DAG のみが表示されます。

DAG プロパティまたは Airflow UI を使用して DAG をロールに割り当てることができます。

Airflow UI でロールに DAG を割り当てる

管理者は、必要な DAG レベルの権限を Airflow UI の適切なロールに割り当てることができます。

このオペレーションは DAG UI ではサポートされていません。

DAG プロパティ内のロールに DAG を割り当てる

DAG を割り当てる DAG グループ化ロールを指定して、DAG に access_control DAG パラメータを設定できます。

Airflow 2 の 2.1.0 より前のバージョンでは、管理者、DAG デベロッパー、または自動プロセスで sync-perm Airflow コマンドを実行して、新しいアクセス制御設定を適用する必要があります。

Airflow 2.1.0 以降のバージョンでは、このコマンドを実行する必要はなくなりました。これは、スケジューラが DAG を解析するときに DAG レベルの権限を適用するためです。

dag = DAG(
  access_control={
    'DagGroup': {'can_edit', 'can_read'},
  },
  ...
  )

Airflow UI で監査ログをユーザーにマッピングする

Airflow UI の監査ログは、Google ユーザーアカウントの数値 ID にマッピングされます。たとえば、ユーザーが DAG を一時停止すると、エントリがログに追加されます。

監査ログは、Airflow UI の [閲覧] > [監査ログ] ページで表示できます。

一般的なエントリでは、[オーナー] フィールドに数値 ID 「accounts.google.com:NUMERIC_ID」が表示されます。[セキュリティ] > [ユーザーの一覧表示] ページで、数値 ID をユーザーのメールアドレスにマッピングできます。このページは Admin ロールを持つユーザーが使用できます。

Google ID（メールアドレス）とユーザーアカウント（ユーザー ID）の関係は固定されていません。