メインコンテンツまでスキップ
バージョン: 4.x

Built-in Authorization

主要な概念​

Authorizationとは、ユーザーアイデンティティがDorisリソースへのアクセスと操作において制限されるメカニズムを指します。

Dorisは権限管理にRole-Based Access Control (RBAC)モデルを使用します。

権限​

権限はノード、カタログ、データベース、またはTableに適用されます。異なる権限は異なる操作の許可を表します。

すべての権限​

許可Object タイプデスクリプション
Admin_privGlobalスーパー管理者権限。
Node_privGlobalノード変更権限。FE、BE、BROKERノードの追加、削除、廃止を含みます。
Grant_privGlobal, カタログ, Db, Table, Resource, Workload Group権限変更権限。権限の付与、取り消し、ユーザー/ロールの追加/削除/変更などの操作を許可します。
他のユーザー/ロールに権限を付与する場合、バージョン2.1.2以前では、現在のユーザーは対応するレベルのGrant_priv権限のみが必要でした。バージョン2.1.2以降では、現在のユーザーは付与したいリソースの権限も必要です。
他のユーザーにロールを割り当てるには、GlobalレベルのGrant_priv権限が必要です。
Select_privGlobal, カタログ, Db, Table, ColumnSelect権限。データの照会を許可します。
Load_privGlobal, カタログ, Db, TableLoad権限。Load、Insert、Deleteなどを含みます。
Alter_privGlobal, カタログ, Db, TableAlter権限。データベース/Tableの名前変更、カラムの追加/削除/変更、パーティションの追加/削除などを含みます。
Create_privGlobal, カタログ, Db, TableCreate権限。カタログ、データベース、Table、ビューの作成を許可します。
Drop_privGlobal, カタログ, Db, TableDrop権限。カタログ、データベース、Table、ビューの削除を許可します。
Usage_privResource, Workload GroupResourcesとWorkload GroupsのUsage権限。
Show_view_privGlobal, カタログ, Db, TableSHOW CREATE VIEW実行権限。

ロール​

Dorisでは、カスタム名のロールを作成できます。ロールは権限の集合として見ることができます。新しいユーザーにロールを割り当てると、そのロールの権限が自動的に付与されます。その後のロールの権限変更も、そのロールに属するすべてのユーザーの権限に影響します。

Built-inロール​

Built-inロールは、Dorisによって作成されるデフォルトのロールで、operatorとadminを含むデフォルト権限を持ちます。

  • operator: Admin_privとNode_privを持ちます
  • admin: Admin_privを持ちます

ユーザー​

Dorisでは、user_identityがユーザーを一意に識別します。user_identityはuser_nameとhostの2つの部分で構成され、usernameはユーザー名です。hostはユーザーが接続するホストアドレスを識別します。

Authorization メカニズム​

Dorisの権限設計は、RBAC (Role-Based Access Control)モデルに基づいており、ユーザーとロール、ロールと権限を関連付け、ユーザーがロールを通じて間接的に権限を持ちます。

ロールが削除されると、ユーザーは自動的にそのロールのすべての権限を失います。

ユーザーとロールの関連付けが解除されると、ユーザーは自動的にそのロールのすべての権限を失います。

ロールの権限が追加または削除されると、ユーザーの権限も変化します。

┌────────┐        ┌────────┐         ┌────────┐
│  user1 ├────┬───►  role1 ├────┬────►  priv1 │
└────────┘    │   └────────┘    │    └────────┘
              │                 │
              │                 │
              │   ┌────────┐    │
              │   │  role2 ├────┤
┌────────┐    │   └────────┘    │    ┌────────┐
│  user2 ├────┘                 │  ┌─►  priv2 │
└────────┘                      │  │ └────────┘
                  ┌────────┐    │  │
           ┌──────►  role3 ├────┘  │
           │      └────────┘       │
           │                       │
           │                       │
┌────────┐ │      ┌────────┐       │ ┌────────┐
│  userN ├─┴──────►  roleN ├───────┴─►  privN │
└────────┘        └────────┘         └────────┘

上記のように:

user1とuser2は両方ともrole1を通じてpriv1権限を持っています。

userNはrole3を通じてpriv1権限を、roleNを通じてpriv2とprivN権限を持っているため、userNはpriv1、priv2、privN権限を持っています。

注意事項​

  • 利便性のため、ユーザーに直接権限を付与することができます。内部的には、各ユーザーに対してデフォルトロールが作成され、ユーザーへの権限付与はデフォルトロールへの権限付与と同等です。
  • デフォルトロールは削除できず、他のユーザーに割り当てることもできず、ユーザーが削除されると自動的に削除されます。

関連コマンド​

ベストプラクティス​

以下はDorisの権限システムを使用する例です。

  1. シナリオ1

    Dorisクラスターのユーザーは管理者（Admin）、開発エンジニア（RD）、ユーザー（クライアント）に分けられます。管理者はクラスター全体に対してすべての権限を持ち、主にクラスターのセットアップやノード管理などを担当します。開発エンジニアはビジネスモデリングを担当し、データベースとTableの作成、データのインポートと変更などを行います。ユーザーは異なるデータベースとTableにアクセスしてデータを取得します。

    このシナリオでは、管理者にはADMINまたはGRANT権限を付与できます。RDには任意または指定されたデータベースとTableに対してCREATE、DROP、ALTER、LOAD、SELECT権限を付与できます。Clientには任意または指定されたデータベースとTableに対してSELECT権限を付与できます。同時に、複数ユーザーの権限管理を簡素化するため、異なるロールを作成できます。

  2. シナリオ2

    クラスターには複数のビジネスがあり、各ビジネスは1つ以上のデータセットを使用する場合があります。各ビジネスは独自のユーザーを管理する必要があります。このシナリオでは、管理者は各データベースに対してDATABASEレベルのGRANT権限を持つユーザーを作成できます。このユーザーは指定されたデータベースに対してのみ権限を付与できます。