Snowflakeの便利な機能、FUTUREオプションを使って思わぬ落とし穴にハマったときのことについての話です。
2024年末くらいの話なので時差があります。（最新の情報をご確認ください）
先にいうと単に仕様を見落としていただけなのですが、意外と気づかない人も多いのでは？と思いメモとして残します。
※少しややこしく難しいかもしれません😵
FUTUREオプション/OWNERSHIP権限とは？
ロールや権限周りの話になりますので、そもそもSnowflakeのロールとは？という方は初めに以下の記事をよんでみてください！
Snowflake オブジェクトへのアクセス制御
Snowflake ロール設計
FUTUREオプション
運用において、オブジェクトが増える度にその権限をロールに付与するのは手間がかかりますよね。
それを適切なロールに自動で付与されるようする設定がFUTUREオプションです。
新規オブジェクトの権限をロールに自動付与することができます。
例えば次のようなコマンドで適応されます。
GRANT ALL ON FUTURE TABLES IN SCHEMA SC1 TO ROLE SCHEMAADMIN;
SC1スキーマ配下の新規テーブルのALL権限をSCHEMAADMINロールに自動付与するコマンドです。
スキーマ作成後テーブルを作成する度に権限を付与しなくて済むよう、事前にこのFUTUREオプションで設定をします。
メリット
・自動的に付与されるため運用にかかる工数が減る
・人手で権限を付与しないため、誤った付与先を指定することなどを防ぐ
OWNERSHIP権限
OWNERSHIP権限(所有権)は、そのオブジェクトに対する包括的な操作が可能であり、オブジェクトを削除できる唯一の権限です。
個々のオブジェクトにつきOWNERSHIP権限が一つのロールに付与されます。
デフォルトではオブジェクトを作成したロールにOWNERSHIP権限が自動的に付与されます。
例えば、単純にSYSADMINロールで全てのオブジェクトを作成した場合、それら全てのOWNERSHIP権限はSYSADMINロールにつきます。
FUTUREオプションとOWNERSHIP権限による制御
上記の二つを活用すると以下のようなことができます。
権限の強いロールでオブジェクトを作成した場合でも、特定の階層下位ロールにOWNERSHIP権限を付与することができます。FUTUREプションを使用したオブジェクトはどのロールで作成してもこれが適用されるため作成時のロール考慮が不要になります。
これを使わない手はないですよね！
ということで、これを活用しました！
やりたかったこと
※登場オブジェクトが多いのでまとめました参考までに
・データレイク：今回はS3
・ストレージ統合：外部クラウドストレージ用に生成されたアクセス管理エンティティをストレージの場所（Amazon S3等）とともに格納するSnowflakeオブジェクト
・外部ステージ：Snowflakeからデータレイク（今回はS3）を参照するための窓のようなもの
・APPADMIN：ETLアプリ用に準備したロール
・SCHEMAADMIN：スキーマ管理者用に準備したロール
・SYSADMIN：Snowflakeのシステム定義ロール
・ステージのOWNERSHIP：ステージに対する包括的な制御を付与します
・ステージのUSAGE：SQLステートメントで外部ステージオブジェクトを使用できるようにしREADとWRITE権限を含みます
・ストレージ統合のUSAGE：統合を使用する他のコマンドを実行するときに統合を参照できるようにします
1. ETLアプリ用のロールでデータレイクからSnowflakeへデータを一括ロードする
2. スキーマオブジェクトであるステージのOWNERSHIPがスキーマ管理者のロールに自動付与される
この2点を実現できるように次のように設定を行いました。
1. ETLアプリ用のロールでデータレイクからSnowflakeへデータを一括ロードする
→バルクロードをするため、外部ステージを作成しデータレイクとの統合設定をする
ETLアプリ用のロールに外部ステージのUSAGEを付与する（①にあたる。※バルクロードするための権限は外部ステージのUSAGEのみでOK 参考）
2. スキーマオブジェクトである外部ステージのOWNERSHIPがスキーマ管理者に自動付与される
→SC1スキーマ配下のステージのOWNERSHIPがスキーマ管理者のロールに自動付与されるようFUTUREオプションを利用
GRANT OWNERSHIP ON FUTURE STAGES IN SCHEMA SC1 TO ROLE SCHEMAADMIN;
--SCHEMAADMINはスキーマ管理者用に作成したロール
（余談）ロール設計の話になりますが、今後の拡張性を考慮しスキーマ管理者用のロールを新たに準備、スキーマオブジェクト（スキーマ配下のオブジェクト）のOWNERSHIP権限はスキーマ管理者に付与されるのが妥当だという考えからこのように設定しました。参考記事
起きたこと
その後、新規外部ステージを作成しCOPYコマンドによるバルクロードを実行しようとしたのですが、ETLアプリ用のロールで実行できず以下のエラーが発生しました。
Error:SQL access control error: Insufficient privileges to operate on integration xxxxx
公式サイトの手順通り統合も作成できており、十分な権限もついているなのになぜ？と原因がわからなかったのですが、偶然この簡潔な記事を見つけ救われました。
エラーメッセージ、そしてそのエラーが起きている状況が完全に一致🥺
この記事を見てから公式サイトも確認すると以下のように書いてありました。
ステージの所有者（つまり、ステージに対する OWNERSHIP 権限を持つロール）には、ストレージ統合に対する USAGE 権限が必要です
ストレージ統合のUSAGE権限とステージのOWNERSHIP権限は同じロールにいないとだめですよ、ということだと理解しました。
図にするとこんな感じ（OK例）↓
今回起きたのはこちら（NG例）↓
FUTUREオプションを使用したことでルールに違反してしまい作動しなくなった、ということだったようです。
外部ステージを作成したロールが、外部ステージとして認識するのに必要なストレージ統合を持つべきなのは納得（1つのロールで「外部ステージの作成～統合の作成」の一連の作業をすることが予想されるため）ですが、
実際に運用しようとなったときに今回のようなfutureオプションを使用した例外も考えられるよな～と少し納得しきれない部分もあります。
そもそももっとわかりやすく目立つように書いてくれてもいいのではと思ったり
・FUTUREオプションを使用した場合に対象のロール同士が継承関係にあればOK
・FUTUREオプションする場合このルールは無効 etc.
ような仕様になったらいいなと思いました。
ということで今回の対応としては、FUTUREオプション*OWNERSHIP権限の制御を優先し、
以下のようにスキーマ管理者にストレージ統合のUSAGEを持たせました。
ただ、SCHEMAADMINは運用の中でバルクロードを実行しないのにストレージ統合のUSAGEを持つことに個人的に違和感があります（ちょっと無理矢理感&この一手間をいつか忘れそう）。。。
GRANT USAGE ON INTEGRATION (ストレージ統合の名前) TO ROLE SCHEMAADMIN;
この対応の結果、
・ステージのOWNERSHIPとストレージ統合のUSAGEが同じロール(この場合SCHEMAADMIN)に共存している
→ルールに従っているので、APPADMINでバルクロード可能✅
→やりたかったことを実現できる✅
まとめ
・FUTUREオプションは運用を効率的にする便利な機能。権限付与する際に組み合わせて使うと効果的。
・バルクロードする際はストレージ統合のUSAGE権限とステージのOWNERSHIP権限は同じロールになるように
・公式の仕様はよく読みましょう（ロールの移動による影響範囲を認識すること）
今回は一次対応としてこのようにしました。
やりたいことを実現できることが一番なので形のいびつさは一旦置いておきます。
ストレージ統合のUSAGEとかステージのUSAGE権限とか名前が似ていてややこしい😵
より良い方法があったら教えてください～