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

この記事には、 Lakeflow ジョブの ID、アクセス許可、特権を管理するための推奨事項と手順が含まれています。

注記

シークレット は、クラスターの Spark ドライバーのログ stdout と stderr ストリームから編集されません。 機密データを保護するために、by Default では、 Spark ドライバー ログは、ジョブ、専用アクセス モード、および標準アクセス モード クラスターに対する CAN MANAGE 権限を持つユーザーのみが表示できます。 Can Attach To または Can Restart の権限を持つユーザーがこれらのクラスターのログを表示できるようにするには、クラスター構成で Spark 構成プロパティ (spark.databricks.acl.needAdminPermissionToViewLogs false) を設定します。

No Isolation 共有アクセス モード クラスタリングでは、Can Attach To、Can Restart、またはCAN MANAGE権限を持つユーザーがSparkドライバー ログを表示できます。ログを読み取ることができるユーザーを CAN MANAGE 権限を持つユーザーのみに制限するには、 spark.databricks.acl.needAdminPermissionToViewLogs を trueに設定します。

SparkSparkクラスター構成に プロパティを追加する方法については、 構成 を参照してください。

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

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

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

たとえば、 ユーザー A が ジョブを作成し、 実行先を ユーザー B に設定すると、ジョブはユーザー B の権限で実行されます。 ユーザー C が ジョブを実行した場合、ジョブは引き続きユーザー B の権限で実行されます。 つまり、自分自身がアクセスできないデータセットから情報を取得するジョブを実行する権限を誰かに与えることが可能です。

ジョブのデフォルト権限

ジョブには、デフォルトで次の権限が設定されています。

• ジョブの作成者に、ジョブに対する IS OWNER 権限が付与されます。
• ワークスペース管理者には、ジョブに対する CAN MANAGE 権限が付与されます。
• ジョブの作成者が 別のユーザーとして実行 に設定されている。
• ジョブ (ジョブ内のタスクを含む) を実行するときは、 実行 ユーザーの権限が使用されます。

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

ジョブの管理者権限

デフォルトにより、ワークスペースの管理者は、ジョブの所有者を変更したり、ワークスペース内の任意のユーザーまたはサービスプリンシパルを 実行者として 設定したりできます。 アカウント管理者は、 RestrictWorkspaceAdmins 設定を構成してこの動作を変更できます。 「ワークスペース管理者を制限する」を参照してください。

ジョブは Unity Catalog の権限とどのように相互作用しますか?

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

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

注記

Unity Catalog グラントとレガシーテーブル ACL には、互換性のあるコンピュートアクセスモードが必要です。 ジョブのコンピュートの設定を参照してください。

権限はいつ評価されますか?

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

権限 としての実行は ジョブの実行中に評価されます。 したがって、各タスクは、タスクの開始時または実行中に権限をチェックする可能性があります。

注記

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

SQL タスクとパーミッション

ファイル タスクは、 実行ユーザーを 完全に尊重する唯一の SQL タスク タイプです。

SQL クエリ、アラート、および従来のダッシュボード タスクは、構成された共有設定を尊重します。

• 所有者としての実行 : スケジュールされた SQL タスクの実行では、常に構成された SQL 資産の所有者の ID が使用されます。
• ビューアーとして実行 : スケジュールされた SQL タスクの実行では、常にジョブの 実行者 フィールドで設定された ID が使用されます。

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

例

次のシナリオは、SQL 共有設定とジョブの 別のユーザーとして実行 設定の相互作用を示しています。

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

ここで、ユーザー B がこの動作を望まなかったとします。 既存の設定から開始すると、次の処理が行われます。

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

ジョブ実行のユーザーとして実行を構成する

別のユーザーとして実行 設定を変更するには、ジョブに対する CAN MANAGE または IS OWNER のアクセス許可が必要です。

実行名 の設定は、自分自身に設定することも、 サービスプリンシパル User 権限があるワークスペース内の任意のサービスプリンシパルに設定することもできます。

ワークスペース UI でジョブの 実行者 設定を構成するには、次の手順を使用して既存のジョブを選択します。

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

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

• サービスプリンシパル
• サービス プリンシパルを管理するためのロール
• 使用できるサービスプリンシパルをリストします。

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

Databricks では、すべての本番運用ジョブについて、次のことを推奨しています。

• サービスプリンシパルを用いた本番運用 ジョブの実行

  ジョブは、デフォルトでジョブ作成者 として実行されます 。 実行 ユーザーが組織を離れると、ジョブが失敗する可能性があります。

  実行をユーザーとして サービスプリンパルシに割り当てた場合、ジョブ実行はサービスプリンシパルの権限を使用し、ユーザーが退会したり権限を変更したりしても変更されません。

  デフォルトでは、ワークスペース管理者はジョブの権限を管理し、必要に応じて所有権を再割り当てできます。

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

• 常にUnity Catalog互換のコンピュート設定を使用する

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

  ジョブとSQLウェアハウスのサーバレスコンピュートは常に Unity Catalogを使用します。

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

  Lakeflow で構成された宣言型パイプライン Unity Catalog には、いくつかの制限があります。 制限事項を参照してください。

• 本番運用ジョブのジョブ権限を制限する

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

  • ジョブ構成を表示したり、実行を監視したりするユーザーには、 CAN VIEW アクセス許可が必要です。
  • ジョブの実行をトリガー、停止、または再開するユーザーには、「 Can Manage Run 」権限が必要です。
  • Can Manage または Is Owner の権限は、本番運用コードの変更を許可されたユーザーにのみ付与します。

ジョブへのアクセスの制御

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

注記

各アクセス許可には、次の表の下位にあるアクセス許可の付与が含まれています。

権限	権限
IS OWNER	デフォルトで 「実行」 に使用される ID。これを上書きするには、「 実行ユーザー」を 設定できます。
CAN MANAGE	構成、タスク、権限などのジョブ定義を編集できます。スケジュールを停止したり再開したりできます。
CAN MANAGE RUN	ジョブの実行をトリガーおよびキャンセルできます。
CAN VIEW	詳細、履歴、ステータスなどのジョブ実行結果を表示できます。

• ジョブの作成者には、デフォルトで IS OWNER 権限があります。

• 1つのジョブに複数の所有者を設定することはできません。

• グループには、所有者として IS OWNER 権限を割り当てることはできません。

• 「今すぐ実行」 によってトリガーされたジョブは、 「今すぐ実行」 を発行したユーザー ではなく、「実行 ユーザー (デフォルトでは所有者)」の権限を想定します。

• ジョブのアクセス制御は 、ジョブとパイプラインの UI に表示されるジョブとその実行に適用されます。以下の場合には適用されません。

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

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

ジョブのアクセス許可レベルについては、「 ジョブ ACL」を参照してください。

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

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

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

ジョブの所有者を管理する

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