新データ基盤におけるSnowflakeのロール設計に、データベースロールをトライしてみた話
こんにちは!GA technologies / RENOSYのデータエンジニアの
常住(つねすみ)です。
前回、DataEngineeringStudy #24への登壇の記事をアップしました。
今回は、上記のnoteでも述べた「テック企業としてのデータ基盤」の
構築内容の1つ、Snowflakeのロール設計の取り組みを共有します。
1:新データ基盤の構成
新データ基盤は以下の構成となります。
データマートは、dbt Cloudを用いてSnowflakeに作成します。
2:ロール設計の要件
dbt Cloudから参照するDWHがSnowflakeになるにあたり、以下の要件がロール設計に求められました。
SnowflakeのベストプラクティスであるFunctional Roleと
Access Roleの組み合わせを採用したいdbt Cloudからの参照権限もロールベースのアクセス制御(RBAC)に
組み込む必要があるなるべくSnowflake上でユーザーにCREATEさせたくない
(理由:野良データマートが増えることを避けたい)カラム単位で見せる見せないをコントロールしたいケースもある
3:Snowflakeでデータベースロールを使用
早速ではありますが、結果的にどういうRBACを実装したのか、
簡単にシェアさせていただきます。
今回、RBACのAccess Role部分にはデータベースロールを採用しました。
大まかではありますが、データベースロールの従来のアカウントロールとの違いは以下となります。
データベースロールはユーザーが選択できるロール一覧の中には出てこないため、Access Roleが増えても、画面にロール一覧がズラッと並ばず、視認性を確保しやすくなります。
最終的なRBACの形としてはこうなりました。(設定は一部のみ抜粋。実際はSTG層やMART層からも設定があります。)
4:実行したSQLコマンド
以下は今回実行したロール作成のコマンドの概要です。
[前提]
ーDatabase/Schema/TableはSYSADMINでCREATEされている
ーDatabaseは以下の3層構造
RAW ローデータ
STG 1次集計
MART データマート
ーSnowflakeのFunctional RoleのOwnerはSECURITYADMIN
[手順]
SYSADMINにチェンジ
USE ROLE SYSADMIN;
Databaseを指定し、2種類のデータベースロールを作る
a:Databaseに紐づくデータベースロール
CRAETE DATABASE ROLE _DATABASE_RAW_RW_AR; ― Read/Write可能
CRAETE DATABASE ROLE _DATABASE_RAW_RO_AR; ― Readのみ可能
※これをSTG、MARTもつくる
b:Database:RAW配下のSchema単位でのデータベースロール
CRAETE DATABASE ROLE _SCHMEA_RAW_A(Schema名)_RW_AR; ― Read/Write可能
CRAETE DATABASE ROLE _SCHMEA_RAW_A(Schema名)_RO_AR; ― Readのみ可能
※これを必要なSchmea分作成する
2-aのデータベースロールに、紐づくDatabaseの必要な権限をGRANTする
― Read/Write
grant usage on DATABASE RAW to database role _DATABASE_RAW_RW_AR
grant create schema on database xxx to database role _DATABASE_RAW_RW_AR;
― Readのみ
grant usage on DATABASE RAW to database role _DATABASE_RAW_RO_AR
※同じことをSTG、MART分実施する
2-bのデータベースロールに、紐づくSchemaのRead/WriteをGRANTする
― Read/Write
grant usage on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
grant create table on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
grant create view on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
― Readのみ
grant usage on schema A(Schema名) to database role _SCHMEA_RAW_A_RO_A;
※これを必要なSchmea分実施する
SECURITYADMINにチェンジ
USE ROLE SECURITYADMIN;
2-bのDbRに紐づくSchema配下のfuture tableをSelectできるようにする
grant select on future tables in schema raw.A to database role _SCHMEA_RAW_A_RW_A;
※これを必要なSchmea分実施する
Functional Roleとなるカスタムロールに、作成したデータベースロールをGRANTする
例:DB単位:grant database role _DATABASE_RAW_RW_AR to role DBT_STANDARD;
例:SCHEMA単位:grant database role raw._SCHMEA_RAW_A_RW_A to role DBT_STANDARD;
※これを必要なカスタムロール・Database・Schema分実施する
Functional Roleに適切なデータベースロールがGRANTされているか確認
SHOW grants to role DBT_STANDARD;
5:クラスメソッドさんのPoC支援
環境構築に先んじて、SnowflakeはFundamentals研修を受けることができ、基本的な概念を学びました。
一方で、dbt CloudはWEB上のドキュメントを見ていても、新たに覚える概念が多く、キャッチアップが難しそうだなと感じていました。また、これまでGit管理などもそこまで行えていなかったため、学ぶ内容がdbt Cloudだけではないことも、独力でやり切るには不安に思う要素でした。
そこで今回、クラスメソッドさんにdbt CloudのPoC支援をお願いしました。
クラスメソッド様が運営されているDevelopersIOで、dbt Cloud導入支援のキャンペーンのバナーを見たのがきっかけで、問い合わせをさせていただきました。DevelopersIOのdbt CloudやSnowflakeなどのモダンデータスタック関連の記事は、このプロジェクトを始める前からもずっと拝読しており、とても参考にしています。
講師はさがらさんにご担当していただき、私含め、dbt CloudのDeveloperになる予定のデータチームのメンバーにハンズオンとトレーニングを行っていただきました。その後約1ヶ月ほど、私とさがらさんで1on1を繰り返しながら、今回の要件に応じたSnowflakeとdbt Cloudの環境の実装を進めました。
データベースロールもこのPoC支援の中でご案内いただき、Access Roleに採用することができました。
正直、この支援をお願いしてなかったら、dbt Cloudの良さをまったく引き出せないデータ基盤になってしまっていたなと思います。非常にたすかりました。。。
6:今後
ロールの設計も終わり、現在は既存の設定の移管と、Snowflakeのユーザーへの開放の準備を進めている最中となります。また進捗や学びなどがあれば、こちらのnoteで共有させていただきます。
GA technologiesではデータエンジニアを引き続き積極採用中ですので、
ご興味を持った方はぜひ以下よりご応募お待ちしております!
カジュアル面談からでも!