Amazon Quick と Snowflake をキーペア認証で接続してみた
札幌オフィスの中川です。
Amazon Quick から Snowflake への接続には、認証方式が複数用意されています。このうちパスワード認証は Snowflake が段階的な廃止を進めており、アプリケーションからの接続にパスワードを使う構成は今後成立しなくなります。
本記事では、パスワードに代わる接続方式のうちキーペア認証を選び、Snowflake のトライアルアカウントを使って、サービスユーザーの作成から接続、SPICE 取り込み、日本語での自然言語質問までを一通り試します。
なぜキーペア認証なのか
Amazon Quick の Snowflake データソースは、ユーザーガイド上はパスワードと OAuth の 2 方式が記載されています。
キーペア認証は AWS 公式ブログで発表された方式で、執筆時点ではユーザーガイドに記載がありません。仕様を確認する場合はブログと API リファレンスを参照してください。API リファレンスの AuthenticationType には KEYPAIR が定義されています。
パスワード以外の選択として OAuth か キーペア があります。
OAuth は Okta のような ID プロバイダー（IdP）を介して認証する方式で、Snowflake と IdP の双方に連携設定が必要です。さらに Quick 側の制約として、ユーザーガイドによるとデータソース作成は API 経由のみで、AWS Secrets Manager の利用が前提です。検証済み IdP として記載されているのも Okta と PingFederate のみです。
一方キーペアは IdP を使わず、コンソールだけで完結します。認証情報の発行や失効を IdP で集中管理したい組織では OAuth が向きますが、まず小さく始めるならキーペアが手軽です。
やってみた
Snowflake のトライアルアカウントを用いて検証します。
データには架空の飲料メーカーの売上サンプルを用います。
Snowflake 側の準備
Quick から接続するために、Snowflake 側に以下を用意します。
- クエリを処理するウェアハウス
- 接続先のデータベース
- Quick に許可する操作を SELECT だけに絞ったロール
- 接続に使うサービスユーザー
Snowsight のワークスペースに次の SQL を貼り付けて実行します。全体を EXECUTE IMMEDIATE の1文に包んであるので、カーソルを文中に置いて実行すれば順番にまとめて作成できます。
EXECUTE IMMEDIATE $$
BEGIN
IF (CURRENT_ROLE() != 'ACCOUNTADMIN') THEN
RETURN 'エラー: ロールを ACCOUNTADMIN に切り替えてから実行してください（現在: ' || CURRENT_ROLE() || '）';
END IF;
-- 1. ウェアハウス（XS・60秒で自動サスペンド）
CREATE WAREHOUSE IF NOT EXISTS QUICK_WH
WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
-- 2. データベース・スキーマ
CREATE DATABASE IF NOT EXISTS BEVERAGE_DEMO;
CREATE SCHEMA IF NOT EXISTS BEVERAGE_DEMO.SALES;
-- 3. テーブル（デモ用の商品マスタと売上明細）
CREATE TABLE IF NOT EXISTS BEVERAGE_DEMO.SALES.PRODUCTS (
PRODUCT_ID VARCHAR(10) NOT NULL,
PRODUCT_NAME VARCHAR(100) NOT NULL,
CATEGORY VARCHAR(50) NOT NULL,
SUB_CATEGORY VARCHAR(50) NOT NULL,
UNIT_PRICE NUMBER(10,0) NOT NULL,
COST_RATE NUMBER(4,2) NOT NULL,
PRIMARY KEY (PRODUCT_ID)
);
CREATE TABLE IF NOT EXISTS BEVERAGE_DEMO.SALES.SALES (
SALE_DATE DATE NOT NULL,
REGION VARCHAR(20) NOT NULL,
PREFECTURE VARCHAR(20) NOT NULL,
CHANNEL VARCHAR(20) NOT NULL,
PRODUCT_ID VARCHAR(10) NOT NULL,
QUANTITY NUMBER(10,0) NOT NULL,
AMOUNT NUMBER(12,0) NOT NULL
);
-- 4. Quick 接続用の最小権限ロール
CREATE ROLE IF NOT EXISTS QUICK_ROLE;
GRANT USAGE ON WAREHOUSE QUICK_WH TO ROLE QUICK_ROLE;
GRANT USAGE ON DATABASE BEVERAGE_DEMO TO ROLE QUICK_ROLE;
GRANT USAGE ON SCHEMA BEVERAGE_DEMO.SALES TO ROLE QUICK_ROLE;
GRANT SELECT ON ALL TABLES IN SCHEMA BEVERAGE_DEMO.SALES TO ROLE QUICK_ROLE;
GRANT SELECT ON FUTURE TABLES IN SCHEMA BEVERAGE_DEMO.SALES TO ROLE QUICK_ROLE;
-- 5. Quick 接続用サービスユーザー（キーペア認証・パスワードなし）
CREATE USER IF NOT EXISTS QUICK_SVC
TYPE = SERVICE
DEFAULT_ROLE = QUICK_ROLE
DEFAULT_WAREHOUSE = QUICK_WH;
GRANT ROLE QUICK_ROLE TO USER QUICK_SVC;
RETURN 'セットアップ完了: QUICK_WH / BEVERAGE_DEMO.SALES (PRODUCTS, SALES) / QUICK_ROLE / QUICK_SVC';
END;
$$;
TYPE = SERVICE はパスワードや SAML SSO でのログインができず、MFA の対象外となるユーザータイプで、Quick のようなアプリケーションからの接続にはこちらを使います。
実行結果としては以下になります。
デモ用のサンプルデータも入れておきます。CSV は Snowsight の Load Data UI からロードしました。列のマッピングをプレビューで確認してからロードできます。
ロードできたか、件数で確認します。
SELECT COUNT(*) FROM BEVERAGE_DEMO.SALES.SALES; -- 31632
キーペアの生成と公開鍵の登録
手元のターミナルで RSA キーペアを生成します。Snowflake のドキュメントに従い、秘密鍵は PKCS#8 形式で、2048 ビット以上の鍵長にします。
# 秘密鍵を生成する。パスフレーズの入力を求められる
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8
chmod 600 rsa_key.p8
# 秘密鍵から公開鍵を生成
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
ここで設定したパスフレーズは、後に Quick 側で入力します。
公開鍵は BEGIN/END のヘッダー行を除き、改行を取り除いた 1 行の文字列にして Snowflake ユーザーに登録します。macOS なら以下のワンライナーでクリップボードに入ります。
grep -v KEY rsa_key.pub | tr -d '\n' | pbcopy
ALTER USER QUICK_SVC SET RSA_PUBLIC_KEY = '<コピーした公開鍵>';
-- 確認。RSA_PUBLIC_KEY_FP に SHA256:... が入っていれば OK
DESCRIBE USER QUICK_SVC;
接続先ホスト名の確認
Quick の設定画面で入力する接続先ホスト名を Snowsight で確認しておきます。左下のアカウントメニューから アカウント名 > View account details を開くと、Account/Server URL としてそのまま使える形式で表示されます。この後の Quick 側の設定で使うので、表示したままにしておきます。
Quick 側でデータソースを作成
ここまでで Snowflake 側の準備は完了です。Quick のコンソールに移り、データソースを作成します。
左メニューから データ > データソースタブ > データソースの作成 をクリックします。
コネクター一覧から Snowflake を選択します。
認証タイプの初期値はパスワードになっているので、KeyPair に切り替えて次のように入力します。
| 項目 | 入力値 |
|---|---|
| 接続タイプ | パブリックネットワーク |
| データベースサーバー | <アカウント識別子>.snowflakecomputing.com |
| データベース | BEVERAGE_DEMO |
| ウェアハウス | QUICK_WH |
| 認証タイプ | KeyPair |
| ユーザー名 | QUICK_SVC |
| プライベートキー | rsa_key.p8 の全文。BEGIN/END ヘッダー込み |
| パスフレーズ | 鍵生成時に設定したもの |
データベースサーバーは表示したままにしておいた Account/Server URL、データベース・ウェアハウス・ユーザー名は最初のセットアップ SQL で作った名前、プライベートキーとパスフレーズは鍵の生成手順で作ったものです。
プライベートキーはヘッダー込みの全文を貼り付けます。Snowflake に登録した公開鍵の「ヘッダーなし 1 行」とは形式が異なるため、混同すると接続に失敗します。
「接続を検証」を押して成功したら、そのままデータソースを作成します。
データセット作成と日本語での質問
続いて、データセットを作成します。データ > データセットタブ > データセットの作成 をクリックし、先ほど作成した Snowflake データソースを選択します。
スキーマを選ぶと、QUICK_ROLE に SELECT 権限を付与したテーブルが一覧に表示されます。SALES を選択します。
データセットの編集画面でクエリモードに SPICE を選択して取り込みます。SPICE は Quick のインメモリエンジンで、取り込んだ後のクエリは SPICE 上のデータで処理されるため、閲覧のたびに Snowflake へ接続しません。
取り込んだデータセットに、日本語で質問してみます。データセットの詳細画面にある チャット をクリックすると、チャットエージェントが開きます。
「自動販売機の売上が多い都道府県トップ5は?」と聞いてみます。チャネルでの絞り込み、都道府県での集計、上位5件の抽出という3段階の指示を日本語のまま解釈して、ランキングの表が返ってきました。「東京都が圧倒的トップで、2位の大阪府の約1.5倍」という要約文も添えられています。
Snowflake 側のデータが日本語でも、接続からデータセット、自然言語質問まで特別な設定なしで通ることが確認できました。
さいごに
Amazon Quick と Snowflake をキーペア認証で接続できることを確認しました。
Snowflake 側のサービスユーザー作成から Quick 側の接続設定までコンソールと SQL だけで完結するので、パスワード廃止後の接続方式としてまず手元で試しやすい構成です。
今回の検証はトライアルアカウントの ACCOUNTADMIN ですべて作成しましたが、実環境で接続を設定する人が Snowflake の管理者権限を持っているとは限りません。サービスユーザーやロールの作成を誰に依頼するか、秘密鍵をどこに保管して誰がローテーションするか、パブリック接続のままでよいかなどは、事前に整理しておく必要だと思いました。
参考
- Amazon Quick Suite now supports key pair authentication to Snowflake data source
- SnowflakeParameters - Amazon QuickSight API Reference
- Connecting to Snowflake - Amazon Quick User Guide
- Key-pair authentication and key-pair rotation - Snowflake Documentation
- Multi-factor authentication (MFA) rollout - Snowflake Documentation
