この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
さがらです。
dbt Cloudでは、TeamプランでもEnterpriseプランでも、「Owner」と「Member」というGroupが用意されています。
これらのデフォルトGroupと、Enterpriseエディションで自分が作成したGroupを併せて使う場合の注意事項について、本記事でまとめます。
前置き：デフォルトGroupのOwnerとMemberについて
まず、dbt Cloudアカウントを受け取った時点で、デフォルトで「Owner」と「Member」が用意されています。
下図は公式Docからの引用ですが、このような違いがあります。
このときの注意点として、「Member」と聞くと一見権限があまりなさそうに見えますが、「Member」は新しいユーザーを招待でき、対象のdbt Cloudアカウント上の全てのdbt Projectのあらゆる設定変更とIDEでの開発が出来るという、とても強い権限を持っています。
「Owner」と「Member」をEnterpriseエディションで使用する場合の注意事項
先に結論を書いておきますが、Enterpriseエディションで定義した各dbt projectごとのGroupと、デフォルトの「Owner」や「Member」のGroupをあるユーザーに同時に設定すると、「Owner」や「Member」の権限が優先され全てのdbt projectに対しての設定変更と開発ができるだけでなく、ユーザーの招待まで可能となってしまうため、注意が必要です。
以下は実際のサンプルです。
例えば、ある1つのdbt projectだけにDeveloperの権限を持つGroup「sagara_permissiontest」を作成していたとします。Developerは対象のdbt projectにおいて、IDEで開発をしたり、Jobsの定義と実行が出来るレベルの権限です。
この上で、あるユーザーを「Member」Groupと「sagara_permissiontest」Groupに割り当てます。
そして、対象のユーザーでdbt Cloudにログインすると、対象のdbt Cloudアカウント上の全てのdbt projectを開いてIDEで開発することができ、Account Settingsから新しいdbt projectも作れてしまいます。
せっかくPermission Setsを分けて作ったGroupが、何の意味も為さなくなってしまいます。
どうすればいいのか？
EnterpriseエディションにおいてGroupを分けて適切な権限の元dbt Cloudを運用したい場合には、以下の手順に沿ってGroupの設定をしていく必要があります。
※「Owner」と「Member」は削除しなくてもよいのですが、誤って割り当ててしまった場合にトラブルの元になる可能性が高いため、削除することを推奨します。
Account AdminのPermission Setsを持つGroupを作成し、dbt Cloudのアカウント管理者となるユーザーに付与する- ある程度必要なGroupを作成し、各ユーザーに割り当てる ※EnterpriseエディションにおけるPermission Setsの使い分けは、こちらの記事が参考になるはずです。
- 不要となった「Owner」と「Member」は削除する ※削除の手順は公式Docにも記載されております。
最後に
dbt Cloudでは「Member」というGroup名に惑わされないようにしましょう！上述の通り、とても強力な権限を持っているため、Enterpriseエディションでは特に注意しましょう。
4
