単一SnowflakeアカウントでのInternal Marketplace / Organization Listing で利用申請ワークフロー

とーかみです。

Snowflake には、組織内のアカウントに対してデータを公開し、取得・利用可能にする Internal Marketplace （内部Marketplace）という機能があります。

公開されたデータを管理するリソースとして「組織リスト(Organizational listing)」があり、ドキュメントもこれを基準に記載されています。

https://docs.snowflake.com/ja/user-guide/collaboration/listings/organizational/org-listing-about

「組織」という表現の通り、複数のアカウントを束ねる組織の範囲で公開可能なのが Internal Marketplace です。

複数アカウントでの共有はできそうですが、今回は単一のアカウントでの運用でどこまでできるのかを検証してみました。

UI (Snowsight) は、執筆時点のものであるため、メニューの場所等は今後変更になる可能性があります。

やりたいこと

• 単一アカウントで Internal Marketplace にデータを公開
• 別のユーザーから利用申請
• 利用申請を許可
• 許可されたデータを利用
• その他、細かな検証

事前準備

事前準備を行います。環境は Enterprise エディションのトライアルアカウントです。

• 公開用データの準備
• 参照用ユーザーの作成

公開用データの準備

以下のリソースを作成します。

• データベース 1 つ
• スキーマ 2 つ
• テーブル 3 つ
  • 別のスキーマに分かれる形で同じ名前で作る（表記がどうなるかの確認用）
• VIEW 2 つ

USE ROLE ACCOUNTADMIN;
CREATE DATABASE SAMPLE_DB;
CREATE SCHEMA SAMPLE_DB.SAMPLE_SCHEMA;
CREATE SCHEMA SAMPLE_DB.SAMPLE_SCHEMA2;

-- スキーマ1 テーブル
CREATE TABLE SAMPLE_DB.SAMPLE_SCHEMA.NATION AS SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.NATION;
CREATE TABLE SAMPLE_DB.SAMPLE_SCHEMA.REGION AS SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.REGION;

-- スキーマ1 VIEW
CREATE VIEW SAMPLE_DB.SAMPLE_SCHEMA.V_NATION AS SELECT * FROM SAMPLE_DB.SAMPLE_SCHEMA.NATION;
CREATE VIEW SAMPLE_DB.SAMPLE_SCHEMA.V_REGION AS SELECT * FROM SAMPLE_DB.SAMPLE_SCHEMA.REGION;

-- スキーマ2 テーブル（スキーマ1と同じ名前）
CREATE TABLE SAMPLE_DB.SAMPLE_SCHEMA2.NATION AS SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.NATION;

参照用ユーザーの作成

参照用のユーザーを作成します。
姓名と設定とメールアドレス認証が必要です。

CREATE USER IF NOT EXISTS test_reader
    PASSWORD = <>
    LOGIN_NAME = 'TEST_READER'
    DISPLAY_NAME = 'TEST_READER'
    FIRST_NAME = 'TEST'  -- 姓名が入っていないと利用申請ができません
    LAST_NAME = 'READER'  -- 姓名が入っていないと利用申請ができません
    EMAIL = <email> -- メールアドレス認証が必要なのでエイリアスを付与する等で別のメールアドレスを用意します
    DEFAULT_ROLE = TEST_READ_ROLE
    DEFAULT_WAREHOUSE = COMPUTE_WH
    MUST_CHANGE_PASSWORD = FALSE;

必要な情報が不足しているとデータのリクエスト時に以下のようなエラーになります。

単一アカウントで Internal Marketplace にデータを公開

Holizon Catalog > データ共有 > プロバイダー Studio から組織リストを作成します。

Internal Marketplace 向けのため「内部 Marketplace」を選択します。

リストタイトルと統一リストロケーター（識別子）を設定します。
統一リストロケーターは別の名前に変更することもできます。

データ製品を追加

「データ製品を追加」からリストに掲載するデータオブジェクトを追加します。

データベースを選択し、対象のオブジェクトを選択します。
データベースをまたいだ選択はできないようでした。

VIEW を含めて追加しようとしたところ、以下のエラーになりました。標準では Non-secure な VIEW は登録できないようです。
リストを作成するタイミングで作成される SHARE オブジェクトのプロパティを変更することで Non-secure な VIEW を登録できるようですが、今回は SECURE VIEW を作成して登録することにしました。

Non-secure object can only be granted to shares with "secure_objects_only" property set to false.

VIEW を除外し、テーブルだけにすると正常に登録できました。

SECURE VIEW を作成して登録しました。

CREATE SECURE VIEW SAMPLE_DB.SAMPLE_SCHEMA.SV_NATION AS SELECT * FROM SAMPLE_DB.SAMPLE_SCHEMA.NATION;
CREATE SECURE VIEW SAMPLE_DB.SAMPLE_SCHEMA.SV_REGION AS SELECT * FROM SAMPLE_DB.SAMPLE_SCHEMA.REGION;

データ製品の登録後、アクセス制御を設定します。

アクセス許可設定

アクセス許可設定は「誰がアクセスできるか」「誰が見つけられるか」の 2 点を設定します。

• 「組織全体」
  • 組織内にオープンにし、リクエストなしで利用できる状態になります。
• 「選択したアカウントとロール」
  • 限定的なアカウントとロールに対して利用を許可する状態です。
• 「事前承認されたアカウントまたはロールはありません」
  • 初期設定としてアクセスを許可する対象を指定せず、すべて承認制になります。

今回は、 ACCOUNTADMIN のみ許可する設定としました。

続いて、リストを見つけられる（検出できる）範囲を設定します。

• 「組織全体」
  • 組織内にオープンにし、組織内であればリクエスト可能にします。
• 「選択したアカウントとロール」
  • 限定的なアカウントとロールに対して公開し、リクエスト許可にします。
• 「アクセスのないユーザーにより発見されません」
  • 非公開な状態とし、すでに許可が与えられたユーザー以外からはリクエストができない状態にします。

このトライアルアカウント内のすべてのロールからのリクエストを許可する設定としました。

続いて、リクエストに対する承認フローを設定します。

リクエスト承認フローは Snowflake 内部と外部のどちらで処理することもできます。

Snowflake 外でリクエスト承認フローを管理する場合、メールや外部のチケットシステムが利用できるようです。

「詳細はこちら」のリンクは無効のようでしたがおそらく以下のドキュメントが該当するはずです。

https://docs.snowflake.com/ja/en/user-guide/collaboration/listings/organizational/request-approval-workflow

今回は Snowflake でリクエストを管理することにしました。
承認用の通知先メールアドレスを登録します。
また、ここで登録するメールアドレス以外にも承認を許可するロールを設定できます。

保存して設定を完了します。

設定後、そのまま公開することはできず、サポート連絡先を設定が必要でした。

設定後、公開ボタンが押せるようになり、ボタンを押すことでリストを公開できました。

別のユーザーから利用申請

ここからは作成した参照用ユーザーに切り替えて確認します。

Horizon Catalog > カタログ > 内部 Marketplace から共有されたリストを確認します。
※公開操作用の プロバイダー Studio とは異なります

公開したリストが表示されていることが確認できます。

リストを開き、「アクセスをリクエスト」ボタンから利用申請をします。

リクエストは「どのロールに権限を付与するか」「アクセスの理由」を記入してリクエストを送信します。

利用申請を許可

管理者でリクエスト通知を確認します。
以下のようなメールが届いていました。

VIEW REQUEST から、リクエスト内容を確認し、承認します。
このとき、申請されたロールとは別のロールに対してリクエストを許可することができます。
今回は変更せずそのまま承認します。

承認したリクエストは、別のタブの一覧に表示されます。

リクエストが許可されると、参照用ユーザーのメールアドレスに対してリクエストが許可された旨のメールが届いていました。

許可されたデータを利用

参照用ユーザーからリストを確認すると、リクエストではなく「ワークシートのクエリ」に変わっていました。

ワークシートに切り替えると、「データ製品」に許可されたオブジェクトが表示されていました。

クエリ時は以下のように ORGDATACLOUD$INTERNAL${リスト名}.{スキーマ}.{テーブル}; の形式でテーブルを指定します。

select * from ORGDATACLOUD$INTERNAL$SAMPLE_LIST_01.SAMPLE_SCHEMA.NATION;

その他動作確認

公開して申請して許可されたら利用できるところまで確認できました。
その他の「これをやったらどうなる？」を確認していきます。

許可済みリストにテーブルを追加

リクエストが許可され、データが利用できる状態でリストにテーブルを追加してみます。

テーブルを追加します。

追加前の参照ユーザーからアクセス可能なデータ

追加後の参照ユーザーからアクセス可能なデータ

リストに追加したデータは追加リクエストなしで利用できました。
（追加してすぐというわけではなくしばらくしてから表示されました）

許可済みリストからテーブルを除外

許可されたリストからテーブルを除外してみます。

除外後の参照ユーザーからアクセス可能なデータ

リストから削除したデータは利用できなくなりました。
スキーマ配下の利用可能なデータがゼロになるとスキーマごと表示されなくなるようです。

許可済みリストのテーブルが削除されたら

許可されたリストに登録されているテーブルを削除（DROP）したらどうなるか確認してみます。

DROP TABLE SAMPLE_DB.SAMPLE_SCHEMA.NATION;

> NATION successfully dropped.

DROP 自体は特にエラーなく成功しました。

削除後の参照ユーザーからアクセス可能なデータ

リストから削除したデータは利用できなくなりました。

リストの対象テーブル一覧からも除外されていました。

権限どこで管理されているか

組織リストのアクセス許可がどこで管理されているか確認します。

許可を与えた参照ユーザー用のロール TEST_READ_ROLE に対して GRANT はされていませんでした。

SHOW GRANTS TO ROLE TEST_READ_ROLE;

組織リスト LISTING の一覧は以下の SQL で確認できます。

SHOW LISTINGS;

権限については DESC LISTING の manifest_yaml に YAML 形式で管理されています。

DESC LISTING SAMPLE_LIST_01;

title: "sample_list_01"
organization_profile: "INTERNAL"
organization_targets:
  access:
  - account: "<アカウントID>"
    roles:
    - "ACCOUNTADMIN"
    - "TEST_READ_ROLE"
  discovery:
  - account: "<アカウントID>"
locations:
  access_regions:
  - name: "ALL"
approver_contact: "<承認者メールアドレス>
support_contact: "<問合せ先メールアドレス>"
request_approval_type: "REQUEST_AND_APPROVE_IN_SNOWFLAKE"

権限を剥奪するには

許可した権限を剥奪するには、リストのアクセス許可から対象のロールを除外します。

権限剥奪後、リストのページを開くと、再度アクセスをリクエスト可能な状態に戻っていました。

エクスプローラー上は「アクセスなし」と表示されていました。

リストの削除

最後に、リストを削除してみます。

まず非公開にする必要があります。
右上のメニューから非公開にする操作を行います。

ただし、データ製品を取得したコンシューマーは引き続きデータ製品にアクセスできます とありますが、同一アカウントの場合、アクセスはできなくなりました。（後述）

一覧上のステータスが「非公開済み」になっています。

参照用ユーザーからもリストが表示されなくなりました。

エクスプローラー上からも表示されなくなり、クエリを実行してもエラーになりました。

非公開にしたリストは再度公開でき、権限も復活します。

右上のメニューの「リストを削除」から削除します。

復活はできないため非公開のときよりも強い警告が表示されます。
（同じロケーターで再作成はできます）

削除されると一覧上からも消えます。

まとめ

単一の Snowflake アカウントでの Internal Marketplace / Organization Listing の設定とデータを利用するまでの流れを検証しました。

リクエストの最小単位がリストになるため、どのような単位でリストを作るかは運用を考慮して決める必要がありそうです。

（部分的に選択できるのであれば、データオーナー単位のリストを作成し、必要なデータのみ申請/許可するようなことができそうなので今後に期待です）

とはいえ、対応している範囲では思ったより簡単にワークフローの設定まで実現することができました。

特に非公開・削除時の挙動は、単一のアカウントでの動作とマルチアカウントでの動作の違いもありそうですので検証の上でご利用ください。