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

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

注：

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

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

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

ジョブのデフォルト権限

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

  • ジョブの作成者には、IS OWNER アクセス許可が付与されます。

  • ワークスペース管理者には、CAN MANAGE 権限が付与されます。

  • ジョブの作成者が [別のユーザーとして実行] に設定されている。

ジョブの管理者権限

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

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

Jobs run as the identity of the user in the Run as setting. This identity is evaluated against permission grants for the following:

  • Unity Catalog で管理されるアセット (テーブル、ボリューム、モデル、ビューなど)。

  • レガシー テーブルアクセスコントロール リスト (ACL) は、レガシー Hive metastore.

  • コンピュート、ノートブック、クエリ、およびその他のワークスペースアセットの ACL。

  • Databricks secrets. See Secret management.

注：

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

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

file タスクは、実行をSQL ID として 完全に尊重する唯一の タスクの種類です。

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が使用されます。

ジョブ実行の ID を構成する

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

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

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

  1. サイドバーのワークフローアイコン［ワークフロー］をクリックします。

  2. 「名前」列で、ジョブ名をクリックします。

  3. 「ジョブの詳細」サイドパネルで、「実行」フィールドの横にある鉛筆アイコンをクリックします。

  4. ユーザーまたはサービスプリンシパルを検索して選択します。

  5. [保存]をクリックします。

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

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

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

  • ジョブ所有権をサービスプリンシパルに割り当てる

    ジョブを所有するユーザーが組織を離れると、ジョブが失敗する可能性があります。 サービスプリンシパルを使用して、ジョブを従業員の離職に対して堅牢にします。

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

  • 実行 本番運用 ジョブ using a サービスプリンシパル

    ジョブは、デフォルトではジョブ所有者の権限を使用して実行されます。 サービスプリンシパルに所有権を割り当てる場合、ジョブ実行ではサービスプリンシパルの権限が使用されます。

    Using service principals for production jobs allows you to restrict write permissions on production data. If you run jobs using a user’s permissions, that user needs the same permissions to edit the production data required by the job.

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

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

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

    For jobs with classic compute, Databricks recommends shared access mode for supported workloads. Use single user access mode when required.

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

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

    ジョブの実行をトリガー、停止、または再開するユーザーには、「 Can Manage 実行 」権限が必要です。

    ジョブ構成を表示したり、実行を監視したりするユーザーには、 表示可能 アクセス許可が必要です。

    「 Can Manage 」または 「Is Owner 」の権限は、本番運用コードの変更を許可されたユーザーにのみ付与します。

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

Job access control enables job owners and administrators to grant fine-grained permissions on jobs. The following permissions are available:

注：

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

権限

権限

所有者です

デフォルト としての実行 に使用される ID。

Can Manage

ユーザーは、権限を含むジョブ定義を編集できます。 ユーザーはスケジュールを停止したり、再開したりできます。

ジョブ実行を管理可能

ユーザーは、ジョブの実行をトリガーおよびキャンセルできます。

CAN VIEW

ユーザーはジョブの実行結果を表示できます。

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

ジョブ権限を設定する

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

  1. サイドバーのワークフローアイコン［ワークフロー］をクリックします。

  2. 「名前」列で、ジョブ名をクリックします。

  3. [ジョブの詳細] パネルで、[アクセス許可の編集] をクリックします。[権限設定] ダイアログが表示されます。

  4. [Select User, Group or Serviceプリンシパル] フィールドをクリックし、ユーザー、グループ、またはサービスプリンシパルの入力を開始します。このフィールドでは、ワークスペースで使用可能なすべての ID が検索されます。

  5. [追加] をクリックします。

  6. [保存]をクリックします。

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

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