LakeflowジョブのID、アクセス許可、特権を管理する

Lakeflow ジョブでは、ジョブを表示、実行、管理できるユーザーを制御する ジョブ特権 と、ジョブがデータやその他のリソースにアクセスするために使用する ID を決定する権限 として実行 という 2 つのアクセス許可セットが使用されます。 この記事では、ガバナンスのベスト プラクティスと共に、両方について説明します。

注

シークレット は、クラシック コンピューティング リソースの Spark ドライバーの stdout および stderr ストリームから編集されません。 機密データを保護するために、既定では、Spark ドライバー ログは、ジョブ コンピューティングと専用または標準のアクセス モードで汎用コンピューティングに対する CAN MANAGE アクセス許可を持つユーザーのみが表示できます。 同じ既定値は、プールから作成されたコンピューティング リソースにも適用されます。 CAN ATTACH TO または CAN RESTART 権限を持つユーザーがログを表示できるようにするには、コンピューティングの Spark 構成フィールドに次のプロパティを設定します: spark.databricks.acl.needAdminPermissionToViewLogs false。

分離共有アクセス モードのないレガシ コンピューティングでは、CAN ATTACH TO、CAN RESTART、CAN MANAGE アクセス許可を持つユーザーが Spark ドライバー ログを表示できます。 ログを閲覧できるユーザーを "管理可能" アクセス許可を持つユーザーのみに制限するには、spark.databricks.acl.needAdminPermissionToViewLogs を true に設定します。

spark.databricks.acl.needAdminPermissionToViewLogsはコンピューティング レベルの Spark プロパティであるため、必要な各コンピューティングで設定する必要があります。 外部オーケストレーターによってトリガーされるものなど、jobs/runs/submit を介して送信されるエフェメラルなジョブ実行の場合は、送信時に、必要な new_cluster.spark_conf エントリと併せて access_control_list でそのプロパティを設定します。

ジョブ特権と実行ユーザー

ジョブはAzure Databricks内のオブジェクトであり、それらのジョブにアクセスしたり管理したりできる権限を持ちます。 このページでは、これらの特権を ジョブ特権 (またはアクセス許可) として説明します。

ジョブは、そのジョブが参照するリソースに対して操作を行う独自の権限を持つユーザー (またはプリンシパル) に代わって実行され、タスクを処理します。 ジョブが動作するユーザーは 実行 ユーザーと呼ばれ、これらの権限はこのページで 実行権限 (またはアクセス許可) と呼ばれます。 実行ユーザーとしての権限は、ジョブを実行するときに使用されます。

たとえば、 ユーザー A がジョブを作成し、[ ユーザーとして実行 ] を ユーザー B に設定すると、ジョブはユーザー B の特権で実行されます。 ユーザー C がジョブを実行しても、ジョブはユーザー B の特権で実行されます。 これは、自分がアクセスできないデータセットから情報を取得するジョブを実行する機能を他のユーザーに提供できることを意味します。

ジョブの既定の特権

ジョブには、既定では次の権限が設定されています。

  • ジョブを作成した者には、ジョブの IS OWNER 権限が付与されます。
  • ワークスペースの管理者は、そのジョブに対して「管理可能」のアクセス許可が付与されます。
  • ジョブの作成者は、Run as に設定されます。
  • [ユーザーとして実行] のアクセス許可は、ジョブの実行時に使用されます (ジョブ内のタスクを含む)。

既定では作成者を所有者と 実行 ユーザーの両方に設定するため、既定ではジョブを実行するときに作成者の特権が使用されます。 Databricks では、所有者の特権とは別に特権を制御できるように、また所有者が特権を離れたり変更したりしたときにジョブが中断されないように、ユーザー として実行 をサービス プリンシパルに変更することをお勧めします。

ジョブの管理者権限

既定では、ワークスペース管理者は、ジョブ所有者または Run as 構成をワークスペース内の任意のユーザーまたはサービス プリンシパルに変更できます。 アカウント管理者は、このビヘイビアーを変更する RestrictWorkspaceAdmins 設定を構成できます。 「ワークスペース管理者を制限する」をご覧ください。

ジョブが Unity カタログのアクセス許可と対話する方法

ジョブは、[実行するアカウント名] 設定のユーザーの ID として実行されます。 タスクを実行すると、この ID は、これらのタスクで使用される可能性のある次のリソースに対するアクセス許可付与に対して評価されます。

  • テーブル、ボリューム、モデル、ビューなど、Unity カタログ管理アセット。
  • レガシ Hive メタストアに登録されているアセットのレガシ テーブル アクセス制御リスト (ACL)。
  • コンピューティング、ノートブック、クエリ、およびその他のワークスペース資産の ACL。
  • Databricks のシークレット。 「シークレットの管理」を参照してください。

注

Unity カタログの許可とレガシ テーブル ACL には、互換性のあるコンピューティング アクセス モードが必要です。 「ジョブのコンピューティングの構成」を参照してください。

特権が評価される場合

ジョブ特権は、ユーザーがジョブの編集や実行など、そのジョブに対してアクションを実行したときに評価されます。

Run as 特権は、ジョブ実行中に評価されます。 そのため、各タスクは、タスクの開始時または実行中に特権を確認できます。

注

ジョブ実行の開始時にすべての 実行 権限が検証されるわけではありません。 ジョブの実行中にユーザー の特権として実行 を変更した場合 (特に特権を削除した場合)、ジョブが完了する前に失敗する可能性があります。

SQL タスクとアクセス許可

ファイル タスクは、Run as ユーザーの設定を完全に反映する唯一の SQL タスク タイプです。

SQL クエリとアラートでは、構成された共有設定が考慮されます。

  • 所有者として実行: スケジュールされた SQL タスクの実行では、構成された SQL アセットのオーナーの ID が常に使用されます。
  • 視聴者として実行: スケジュールされた SQL タスクの実行では、常にジョブ [Run as] フィールドに設定された ID が使用されます。

クエリ共有設定の詳細については、「クエリのアクセス許可を構成する」を参照してください。

例

次のシナリオは、SQL 共有設定とジョブ [Run as] 設定の相互作用を示しています。

  • ユーザー A は、 my_query という名前の SQL クエリの所有者です。
  • ユーザー A は共有設定my_queryしてを設定します。
  • ユーザー B は、my_queryという名前のジョブのタスクとして my_job をスケジュールします。
  • ユーザー B は、my_jobという名前のサービス プリンシパルを使用して実行するように prod_sp を構成します。
  • my_job を実行すると、ユーザー A の ID を使用して my_query を実行します。

ここで、ユーザー B がこのビヘイビアーを望まないと仮定します。 既存の構成から、次の処理が行われます。

  • ユーザー A は、my_query の共有設定をビューアーとして実行するに変更します。
  • my_job が実行されると、識別子 prod_sp が使用されます。

ジョブ実行のための実行ユーザーを設定する

Run as 設定を変更するには、そのジョブに対して "CAN MANAGE" または "IS OWNER" の権限が必要です。

Run as の設定は、自身、またはサービス プリンシパル ユーザーの権限を持つワークスペース内の任意のサービス プリンシパルに設定できます。

ワークスペース UI でジョブの Run as 設定を構成するには、次の手順に従って既存のジョブを選択します。

  1. Azure Databricksワークスペースのサイドバーで、Jobs & Pipelinesをクリックします。
  2. 必要に応じて、ジョブと自分が所有するフィルターを選択すると、ジョブを簡単に見つけることができます。
  3. リスト内のジョブの名前をクリックします。
  4. [ ジョブの詳細 ] ウィンドウで、[ 実行 ] フィールドの横にある鉛筆アイコンをクリックします。
  5. ユーザー、またはサービス プリンシパルを検索して選択します。
  6. [保存] をクリックします。

サービス プリンシパルに関する詳細については、以下を参照してください。

実行をグループに設定する

Important

この機能は パブリック プレビュー段階です。 このプレビューに参加するには、Azure Databricks アカウント チームにお問い合わせください。

ジョブ の実行 ID をグループに設定する方法は、ユーザーまたはサービス プリンシパルに設定するのと同じように機能します。ジョブは、その ID のアクセス許可を使用して実行されます。 Run as ID がグループである場合、すべてのタスクはそのグループとして実行され、データ アクセスにはグループのアクセス許可が使用され、監査ログには identity_metadata.run_as がグループとして記録されます。 ジョブは常にジョブ サービスの アプリケーション サービス プリンシパルによって実行されるため、 identity_metadata.run_by は常にその ID を記録します。 実行中に作成されたワークスペース資産 (ノートブック、クエリ、ファイル) は、グループによって所有されます。

グループを指定しなくても、ユーザーとして実行を設定することは可能です。 グループを想定してジョブを作成する場合、Azure Databricksはジョブの所有者と実行の両方をグループに自動的に設定します。 グループに対して 実行 を手動で設定することもできます。 グループに対して 実行 を手動で構成するには、次のいずれかを行う必要があります。

  • グループのメンバーになる、または
  • グループが排他アクセスに使用されている場合は、グループに対する権限を持つ。

ワークスペースの UI でグループに Run as を設定するには:

  1. Azure Databricksワークスペースのサイドバーで、Jobs & Pipelinesをクリックします。
  2. リスト内のジョブの名前をクリックします。
  3. [ ジョブの詳細 ] サイド ウィンドウで、[ 実行 ] フィールドの横にある鉛筆アイコンをクリックします。
  4. グループを検索して選択します。
  5. [保存] をクリックします。

タスクは既定で [実行] グループとして実行 されます。 個々のタスクのコンピューティングが別のプリンシパルに割り当てられた専用アクセス モード クラスターである場合、タスクは代わりにクラスター割り当てプリンシパルとして実行されます。

グループをロールとして使用する方法の詳細については、「 ロールベースのアクセス制御 (RBAC)」を参照してください。

ジョブ ガバナンスのベスト プラクティス

Databricks では、すべての生産ジョブに対して次のことをお勧めします。

  • サービス プリンシパルを使用して生産ジョブを実行する

    ジョブは、既定でジョブ作成者 として実行 されます。 Run as ユーザーが組織から去った場合、このジョブは失敗する可能性があります。

    実行ユーザーとしてサービス プリンシパルを割り当てると、ジョブの実行にはサービス プリンシパルの権限が使用され、ユーザーが組織を離れたり、権限が変更されたりしても影響を受けません。

    既定では、ワークスペース管理者はジョブのアクセス許可を管理し、必要に応じて所有権を再割り当てできます。

    運用ジョブにサービス プリンシパルを使用すると、運用データに対する書き込みアクセス許可を制限することもできます。 ユーザーのアクセス許可を使用してジョブを実行する場合、ジョブに必要な運用データを編集するには、そのユーザーと同じアクセス許可が必要です。

  • Unity カタログ互換のコンピューティング構成を常に使用する

    Unity Catalog データ ガバナンスでは、サポートされているコンピューティング構成を使用する必要があります。

    ジョブと SQL ウェアハウスのサーバーレス コンピューティングでは、常に Unity カタログが使用されます。

    クラシック コンピューティングを使用するジョブの場合、Databricks では、サポートされているワークロードに対して標準アクセス モードが推奨されます。 必要に応じて専用アクセス モードを使用します。

    Unity カタログで構成された Lakeflow パイプラインには、いくつかの制限があります。 「制限事項」を参照してください。

  • 稼働中の作業における権限を制限する

    ジョブ権限は、ジョブを表示、実行、または管理できるユーザーを制御します。

    • ジョブの構成を表示したり実行を監視したりするユーザーには、表示権限が必要です。
    • ジョブの実行をトリガー、停止、または再起動するユーザーには、 実行管理可能 アクセス許可が必要です。
    • 管理可能または Is Owner 権限のみを、運用コードを変更するために信頼されたユーザーに付与します。

ジョブへのアクセスを制御する

ジョブのアクセス制御により、ジョブの所有者と管理者は、ジョブに対してきめ細かいアクセス許可を付与できます。 次のアクセス許可を使用できます。

注

各アクセス許可には、以下の表に示される下位アクセス許可が含まれています。

権限 付与
所有者 既定で Run as に使用される ID。 実行 ユーザーとして設定して、これを上書きできます。
CAN MANAGE 構成、タスク、アクセス許可など、ジョブ定義を編集できます。 スケジュールを一時停止および再開できます。
実行を管理できます ジョブの実行をトリガーおよび取り消すことができます。
表示可能 ジョブの実行結果 (詳細、履歴、状態など) を表示できます。
  • ジョブの作成者には、既定で IS OWNER アクセス許可があります。
  • 1 つのジョブに複数の所有者を指定することはできません。
  • グループに IS OWNER 権限を所有者として割り当てることはできません。
  • 今すぐ実行 を使用してトリガーされるジョブは、今すぐ実行を発行したユーザーではなく、実行ユーザー (既定では所有者) のアクセス許可を前提とします。
  • ジョブアクセス制御は、ジョブ & パイプライン UI に表示されるジョブとその実行に適用されます。 次の場合には適用されません。

    • モジュールコードまたはリンクされたコードを実行するノートブック ワークフロー。 これらは、ノートブック自体のアクセス許可を使用します。 ノートブックが Git から取得された場合、新しいコピーが作成され、そのファイルは実行をトリガーしたユーザーのアクセス許可を継承します。

    • API によって送信されたジョブ。 API 要求で access_control_list を明示的に設定しない限り、これらはノートブックの既定のアクセス許可を使用します。

ジョブ権限レベルについては、「ジョブ ACL」を参照してください。

ジョブのアクセス許可を構成する

ワークスペース UI でジョブのアクセス許可を構成するには、次の手順を使用して既存のジョブを選択します。

  1. Azure Databricksワークスペースのサイドバーで、Jobs & Pipelinesをクリックします。
  2. 必要に応じて、ジョブ と 私が所有 フィルターを選択します。
  3. ジョブの [名前] リンクをクリックします。
  4. [ ジョブの詳細 ] ウィンドウで、[ アクセス許可の編集] をクリックします。 [アクセス許可の設定] ダイアログが表示されます。
  5. [ユーザー、グループ、またはサービス プリンシパルの選択...] フィールドをクリックし、ユーザー、グループ、またはサービス プリンシパルの入力を開始します。 このフィールドは、ワークスペース内で使用可能なすべての ID を検索します。
  6. [追加] をクリックします。
  7. [保存] をクリックします。

既存のアクセス許可を変更または削除するには、[ アクセス許可の編集 ] をクリックして [アクセス許可の設定] ダイアログを開きます。 アクセス許可を変更するには、ID の横にあるドロップダウンで別のレベルを選択します。 アクセス許可を削除するには、ID の横にある x をクリックします。

ジョブ所有者を管理する

ワークスペース管理者のみがジョブ所有者を編集できます。 ジョブ所有者を 1 人だけ割り当てる必要があります。 ジョブ所有者は、ユーザーまたはサービス プリンシパルにすることができます。

ノートブック タスクと API アクセス

UI を使用してノートブック タスクを実行すると、ユーザーが基になるノートブックにアクセスできる場合にのみ、(ノートブック内の) 出力にアクセスできます。 ただし、API を介して同じジョブを実行すると、API ユーザーがノートブックではなくジョブ自体にのみアクセスできる場合でも、実行出力は API に表示されます。

  • Last updated on