dbt CloudのEnterpriseエディションにおける各Permission Setsの違いをまとめてみた #dbt

さがらです。

dbt CloudではEnterpriseエディションの場合、ユーザーごとにGroupを割り当てて権限管理が可能です。

このGroupですが、「Permission Sets」と「Permission Setsの対象プロジェクト」を紐づけることが可能です。

そしてこのPermission Setsですが、11種類もあります。正直、多いですよねｗ

そこで本記事では、この11種類のPermission Setsごとに出来ることの違いをまとめた上で、私が考える運用時の使い分けについてもまとめてみます。

前置き：Permission Setsを設定するGroupの作成手順

前置きとして、「Permission Setsをどうやって設定するのか」を知らないといけません。

こちらについて、Permission Setsを付与するのはGroupとなるため、Groupの作成手順をまとめた下記の記事が参考になると思います。ぜひ、こちらも併せてご覧ください。

一点補足としては、Account AdminとAccount Viewer以外のPermission Setsでは、下図のように対象とするdbt projectも選択する必要があります。

各Permission Setsの関係

下図は公式Docからの引用ですが、11種類のPermission Setsはこのような関係になっています。

この図にAccount Viewerが掲載されていませんが、「Account Viewerは、Account Adminの下位に位置するPermission Set」と理解してもらえれば大丈夫です。

次章から、各Permission Setsの特徴について記していきます。

Account Admin

Account Adminは、dbt Cloud上の全ての操作が出来るロールです。ユーザーの招待から、各プロジェクトの設定変更まで、あらゆる操作が可能です。

公式Doc上では、出来ることはこのように記載があります。

• Create, delete and modify all projects in an account
• Create, delete, and modify Repositories
• Create, delete, and modify Connections
• Create, delete, and modify Environments
• Create, delete, and modify Jobs
• Create, delete, and modify Groups
• Create, delete, and modify Group Memberships
• Manage notification settings
• Manage account-level artifacts
• View and modify Account Settings
• Use the IDE
• Run and cancel jobs

Account Viewer

Account Viewerは、対象のdbt Cloud上のアカウントの設定やプロジェクト設定、を閲覧だけ出来るユーザーです。

公式Doc上では、出来ることはこのように記載があります。

• View all projects in an account
• View Account Settings
• View Repositories
• View Connections
• View Environments
• View Jobs
• View Groups
• View Group Memberships
• View notification settings
• View account-level artifacts

例えば、アカウントの設定は全て見ることが出来ますが、Editが押すことが出来ません。

加えて、Developも表示されないため、IDEを起動してコードを見ることも出来ません。

Admin

Adminは、対象のdbt projectにおいて、IDEでの開発、EnvironmentやJobの設定、ProjectのRepositoryやConnectionの設定、などすべての操作を行うことが出来る権限です。

ただし、Admin権限の人が新しくdbt projectを作ることが出来ないためご注意ください。（新しいdbt projectは、Account Adminしか作れません。）

公式Doc上では、出来ることはこのように記載があります。

• View project details
• Create, delete, and modify Repositories
• Create, delete, and modify Connections
• Create, delete, and modify Environments
• Create, delete, and modify Jobs
• Create, delete, and modify Group Memberships　※私が試したときにはGroupは作成・変更できませんでした。こちらはdbt Labs社に問い合わせしております。
• Use the IDE
• Run and cancel jobs

例えば、Account Settingsから対象のdbt projectの設定画面を開くことで、RepositoryやConnectionなどの設定を変更することが出来ます。

Git Admin

Git Adminは、対象のdbt projectにおいて、Repositoryの設定が出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• View project details
• Create, delete, and modify Repositories
• View Connections
• View Environments
• View Jobs

Git Adminだけを持っている場合、下図のようにDevelopも表示されないためIDEを見ることも出来ません。

設定できるのは、Account Settingsから対象のdbt projectの設定画面を開くことで、Repositoryの設定を変更するだけです。（Connectionの設定もできそうに見えますが、リンク先でEditが押せないようになっています。）

Team Admin

Team Adminは、対象のdbt Cloudのアカウント内のGroupの管理が出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• View project details
• Create, delete, and modify group memberships
• View Repositories
• View Environments
• View Jobs

Team Adminだけを持っている場合、下図のようにDevelopも表示されないためIDEを見ることも出来ません。

出来ることとしては、Account SettingsからGroup周りの操作が可能です。

注意点として、2022年10月24日時点ではなぜかTeam AdminはAll Projectsしか選べないようになっていました。こちらはドキュメントの仕様ではHas permissions on: Authorized projectsとなっているので、各dbt projectごとに関連するGroupの設定が出来るはずなのですが…

こちらの件は、dbt Labs社に問い合わせをしております。

Database Admin

Database Adminは、対象のdbt projectにおいて、Connectionの設定だけが出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• View project details
• Create, delete, and modify Connections
• View Repositories
• View Environments
• View Jobs

Database Adminだけを持っている場合、下図のようにDevelopも表示されないためIDEを見ることも出来ません。

設定できるのは、Account Settingsから対象のdbt projectの設定画面を開くことで、Connectionの設定を変更するだけです。（Repositoryの設定もできそうに見えますが、リンク先でEditが押せないようになっています。）

Developer

Developerは、対象のdbt projectにおいてIDEを開いて開発したり、Jobの新規設定と実行が出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• Create, delete, and modify Jobs
• Trigger runs
• Use the IDE
• Configure personal developer credentials

まずは、Developを押してIDEを起動して開発することが出来ます。

Jobsにおいても、「Create New Job」を押すことが出来るので新しいJobの設定と実行が可能です。既存のJobの設定変更も出来ます。

一方で、DeveloperはEnvironmentの新規作成や変更は出来ません。

Account Settingsを押せないため、対象のdbt projectのRepositoryやConnectionの設定も出来ません。

Job Admin

Job Adminは、対象のdbt projectにおいて、EnvironmentとJobsの設定だけが出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• View, edit, and create environments
• View connections
• Trigger runs
• View historical runs

Job Adminだけを持っている場合、下図のようにDevelopも表示されないためIDEを見ることも出来ません。

JobsとEnvironmentsから、新規作成と既存のJobやEnvironmentの設定変更が可能です。

Account Settingsを押せないため、対象のdbt projectのRepositoryやConnectionの設定は出来ません。

Job Viewer

Job Viewerは、対象のdbt projectのJobsやEnvironmentの設定を見たり、Jobsの実行履歴を見ることだけが出来る権限です。

公式Doc上では、出来ることはこのように記載があります。

• View environments
• View job definitions
• View historical runs

まず、Job Viewerだけでは下図のようにDevelopも表示されないためIDEを見ることも出来ません。

Jobsは見ることが出来ますが、「Create New Job」が押せないため、新しいJobを作ることが出来ません。既存のジョブの設定や実行履歴を見ることは可能です。

Environmentsも新規作成や設定変更はできず、見ることだけが出来ます。

Analyst

Analystは、IDEを使って開発することだけが出来る権限です。JobやEnvironmentの設定は見ることだけ可能です。

公式Doc上では、出来ることはこのように記載があります。

• Use the IDE
• Configure personal developer credentials
• View connections
• View environments
• View job definitions
• View historical runs

まずは、Developを押してIDEを起動して開発することが出来ます。

Jobsは見ることが出来ますが、「Create New Job」が押せないため、新しいJobを作ることが出来ません。既存のジョブの設定や実行履歴を見ることは可能です。

Environmentsも新規作成や設定変更はできず、見ることだけが出来ます。

Stakeholder

Stakeholderは、主にRead-Onlyユーザーに向けた権限で、対象のdbt projectに関して生成されたドキュメントやデータの鮮度を確かめることが出来ます。

公式Doc上では、出来ることはこのように記載があります。

• View the Read Only dashboard
• View generated documentation
• View generated source freshness reports

下図のようにDevelopが表示されないためIDEを見ることも出来ません。Documentationは押せますので、ドキュメントは見ることが出来ます。

Data Sourcesから、Freshnessを設定している場合には鮮度を確認することができます。

一方で、公式ドキュメントの仕様にJobsやEnvironmentsに関する記述はなかったため見ることは出来ないと思っていたのですが、なぜか見ることが出来ました。（これだとJob Viewerとやれることが変わらないため、dbt Labs社に問い合わせしています。）

1つのdbt projectに対して複数のPermission Setsを割り当てるとどうなるか？

あるプロジェクトに対して、Git AdminとDeveloperを付与してみます。

すると、Git Adminでは押すことの出来ないDevelopが押せるようになり、Developerでは押すことのできないAccount Settingsが押せるようになりました。

Account Settingsからは、対象のdbt projectのRepositoryの設定だけ変更可能でした。これはGit Adminが出来てDeveloperでは出来ないことです。

つまり、1つのdbt projectに対してPermission Setsを複数設定している場合、それぞれの権限で出来ることがただ増えていく、という仕様であることがわかりました。

運用の際はどのように考えればよいか？

ここまで、11個のPermission Setsについて説明してきましたが、どのように使い分ければよいか、多くて難しいと思います。そこで、私の考えを以下に記します。

早速ですが、以下の4つのPermission Setsを使い分ければ基本的には十分だと思います。その上で、Developerだけで足りない場合は必要なPermission Setsを付与して行けばOKです。

• Account Admin
  • dbt Cloudアカウント全体を見て、新しいdbt projectの作成やユーザーの管理まで行う人
• Admin
  • 各dbt projectを管理するリーダー・責任者ポジションの人
• Developer
  • 各dbt projectにおいて、IDEを使って開発を行う人
  • Environmentの設定もさせたい場合はJob Adminも付与する
  • Repositoryの設定もさせたい場合はGit Adminも付与する
  • Connectionの設定もさせたい場合はDatabase Adminも付与する
• Stakeholder
  • Read-Onlyユーザーとして、ドキュメントやデータの鮮度を見る人

最後に

dbt CloudのEnterpriseエディションにおける各Permission Setsの違いと、私の考える運用方法についてまとめてみました。

11個もあるので一見とまどってしまいますが、基本的には上述しました4つのPermission Setsを基準に考えれば、十分に運用は出来るはずです。

dbt CloudのEnterpriseで運用に困っている方の参考になると嬉しいです！