データベースロールに付与されたOWNERSHIP権限が”snowsight UI”に反映されない問題と暫定対策

この記事は

データベースロールに付与されたOWNERSHIP権限が、snowsight UI（ウェブインターフェース）に設定されたデータベースロールを継承するアカウントロールに反映されず、特定の操作が行えない事象を確認したため、本事象の内容と暫定対策をまとめました。

※サポートケース起票済み

 

前提

現在構築中のSnowflake上で、以下の内容でロールを構成していました。

• ファンクショナルロール（アカウントロール）：ユーザへ直接付与し、各種権限はアクセスロールから継承

• アクセスロール（データベースロール）：権限を直接付与し、ファンクショナルロールに付与

ロールをファンクショナルロールとアクセスロールで使い分けることで、権限の可視性を高めつつ、ロール運用にかかる負担を軽減する効果があります。（Snowflakeでもベストプラクティスとされている構成）

https://select.dev/posts/snowflake-rbac-best-practices

また、アクセスロールをデータベースロールが担うことで、ロール選択画面で表示されるロールがファンクショナルロールのみとなったり、アクセスロールの管理をデータベース管理者に委譲できたりなど、いろいろな効果があります。

https://zenn.dev/dataheroes/articles/snowflake-database-role-20240727

 

発生した事象

---

前提のようなロール構成で環境構築を行った後、ファンクショナルロールを設定した状態でsnowsight UIからファイルデータをテーブルにロードしようとしたところ、以下のエラーが発生しました。

エラーの内容は、テーブルへデータをロードする権限が足りていないという内容です。しかし下記のドキュメント通り、データベースロールには、データベースとスキーマのUSAGE権限とテーブルのOWNERSHIP権限が付与されていました。

https://docs.snowflake.com/ja/user-guide/data-load-web-ui#loading-data-using-snowsight

また、このエラーはテーブルだけでなく、ステージへのファイルアップロードでも同様のエラーが発生しました。

 

原因

どうやら今回のケースでは、snowsight上での操作にデータベースロールにOWNERSHIP権限が反映されていないことが原因と思われます。
※以前、snowsightの設定を日本語にしていると似たようなバグもありました

理由としては、

• snowsqlからのPUTコマンドは成功
• stageにあるファイルのCOPY INTOコマンドも成功

• アクセスロールをデータベースロールではなく通常ロールに置き換えるとエラーが解消

という状況があり、権限には問題ないと考えられるためです。

 

対策

上記の内容をサポートケースに問い合わせたところ、下記の回答を頂きました。

本件については、Database Roleを使用している際にSnowsightの一部機能が対応しきれていない動作に関連していると考えられます。
本動作については開発部門にて調査を行っておりますが、結論が出ていない状況となります。

解決には時間がかかりそうで、以下で対応するしかなさそうです。

• 現状の構成のままテーブルやステージにファイルデータをアップロードしたい場合は、snowsqlを用いる

• snowsight UIからファイルデータのアップロードを行いたい場合は、データベースロールへ付与しているOWNERSHIP権限を通常ロールに再付与
• ロール選択画面にアクセスロールが表示されることを許容して、アクセスロールは通常ロールで作成

 

再現

今回発生した事象を、通常のロールとデータベースロールを用いたケースを検証環境で再現してみました。

環境準備

use role sysadmin;
-- データベース
create database verification_db;
-- ウェアハウス作成
create warehouse verification_wh AUTO_SUSPEND = 60 INITIALLY_SUSPENDED = TRUE;

アクセスロールが”通常のロール”のケース

-- スキーマ作成
create schema regular_role_schema;

-- テーブル作成
create table verification_db.database_role_schema.regular_role_table (id varchar);

-- ロール作成
create role granted_regular_role; -- ファンクショナルロール
grant role granted_regular_role to role sysadmin;
create role regular_role; -- アクセスロール
grant role regular_role to role granted_regular_role;

-- 権限付与
use role sysadmin;
grant usage on warehouse verification_wh to role granted_regular_role;

use role securityadmin;
grant usage on database verification_db to role regular_role;
grant usage on schema verification_db.regular_role_schema to role regular_role;
grant ownership on all tables in schema verification_db.regular_role_schema to role regular_role;


-- 権限の状態
show grants to role regular_role;

 

アクセスロールが”データベースロール”のケース

-- スキーマ作成
create schema database_role_schema;

-- テーブル作成
create table verification_db.database_role_schema.database_role_table (id varchar);

-- ロール作成
create role granted_database_role; -- ファンクショナルロール
grant role granted_database_role to role sysadmin;
use role sysadmin;
create database role database_role; -- アクセスロール
grant database role database_role to role granted_database_role;

-- 権限付与
use role sysadmin;
grant usage on warehouse verification_wh to role granted_database_role;

use role securityadmin;
grant usage on database verification_db to database role verification_db.database_role;
grant usage on schema verification_db.database_role_schema to database role verification_db.database_role;
grant ownership on all tables in schema verification_db.database_role_schema to database role verification_db.database_role;

-- 権限の状態
show grants to database role verification_db.database_role;

 

結果

通常ロールで作成されたアクセスロールを継承しているファンクショナルロールを使用した場合

⇒ ロード可能

データベースロールで作成されたアクセスロールを継承しているファンクショナルロールを使用した場合

⇒ ロード不可

OWNERSHIP権限をファンクショナルロール（通常ロール）に付け替えた場合

grant ownership on all tables in schema verification_db.database_role_schema to database role verification_db.database_role;

⇒ ロード可

まとめ

データベースロールを用いたアクセスロールの実装は、表示されるロールが最適化されたり、データベース管理者が異なる場合に、アクセスロールの管理を委譲できる面はメリットになります。

この事象の解決には時間がかかりそうなので、アクセスロールをデータベースロールで作成しようとしている方は、上記の問題があることを念頭にRBACの実装を検討したほうがよさそうです。