PrivateLink 経由で Snowflake と セルフホスト版の GitLab リポジトリの統合を試してみた
2025.08.28はじめに
Snowflake ではリポジトリ ステージと呼ばれる特別な種類のステージを作成することで、リモートリポジトリを Snowflake と統合することができます。
リポジトリ ステージは読み取り専用ですが、現在プレビュー中の Workspace では Git リポジトリと統合することで、Snowflake 側からの変更（コミット、プッシュなど）も直接行えます。
また、Business Critical 以上のエディションであれば、アウトバウンドプライベート接続の機能と組み合わせて、プライベートネットワーク経由で Git リポジトリにアクセスできるようにSnowflake を構成できます。
GitLab のセルフホスト版を使用し、こちらを試してみましたので、設定手順を記事としました。
前提条件
以下の環境を使用しています。
- Snowflake
- Business Ciritical
- PrivateLink の設定には Business Ciritical 以上のエディションが必要
- クラウドリージョン：AWS_US_EAST_1
- Business Ciritical
- GitLab
- GitLab Self-Managed Enterprise Edition
- ネットワーク
- プライベートサブネットに構築
- 前段に ALB を用意し、SSL オフロードにより HTTPS 要求は ALB で終了し、HTTP 経由で GitLab インスタンスと通信を行う
- ACMで証明書を取得済み
- ALB などのリソースは作成済み
- Route53 にて検証用 DNS ホストゾーンを作成済み
- その他
- リポジトリステージの連携時の URL には HTTPS を使用する必要があります
ここでは下図の構成で検証しています。
また、GitLab はすでにインストール済みで踏み台サーバー（Windows Server）から ALB 経由でアクセスできる状態とします。
GitLab のインストール手順は以下の記事をご参照ください。
事前準備
踏み台サーバーから GitLab にログインしグループとプロジェクトを作成しておきます。プロジェクトには Readme を含めておき、このプロジェクトを Snowflake と同期します。
空のプロジェクトを作成
PrivateLink に関する設定
前提条件として ALB までの構成は完了しているので、NLB に関する設定から行います。ALB のセキュリティグループでは、踏み台サーバーと NLB に関連付けるセキュリティグループからの HTTPS 通信を許可します。
NLB 用のターゲットグループの作成
下図のような ALB をターゲットとするターゲットグループを作成します。
NLB の作成
内部向けのロードバランサーを作成します。
リスナーポートには HTTPS を指定します。
NLB のセキュリティグループでは、0.0.0.0/0 のHTTPS（TCP 443） を許可するインバウンドルールを設定しています。
VPC エンドポイントサービスの作成
続けて、AWS 側でエンドポイントサービスを作成します。エンドポイントサービスのメニューから [エンドポイントサービスを作成] をクリックし、以下の設定としました。
- ロードバランサーのタイプ：ネットワーク
- ロードバランサー：上記の手順で作成した NLB を選択
エンドポイントサービスを作成後、Snowflake 側で使用するのでサービス名を確認しておきます。
Snowflake 側：privatelink-account-principal を確認
Snowflake アカウントにログインし、ACCOUNTADMIN 権限で以下を実行します。
SELECT SYSTEM$GET_PRIVATELINK_CONFIG();
出力の内privatelink-account-principalの値を控えておきます。
AWS 側：プリンシパルを許可
AWS 側に戻り、作成したエンドポイントサービスのメニュー で [アクション > プリンシパルを許可] を選択し、「追加するプリンシパル」に Snowflake 側で取得したprivatelink-account-principalの値を入力し [プリンシパルを許可] をクリックします。
Snowflake 側：プライベートエンドポイントのプロビジョニング
上記の設定後、以下のコマンドでプライベートエンドポイントをプロビジョニングします。
USE ROLE ACCOUNTADMIN;
SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
'com.amazonaws.vpce.us-east-1.vpce-svc-xxxxx', --エンドポイントサービスのDNS名
'GitLabインスタンスのFQDN'
);
AWS 側：エンドポイント接続リクエストの承諾
Snowflake 側でエンドポイントをプロビジョニング後、AWS 側のエンドポイントサービスの画面で「エンドポイント接続」タブを開くと、Snowflake 側で作成したエンドポイントの ID が表示されます。こちらを選択し [アクション > エンドポイント接続リクエストの承諾] をクリックします。
承諾後、下図のステータスになります。
ここまでで AWS 関連の連携設定は完了です。
GitLab 側でアクセストークンを発行
Snowflake から GitLab にアクセスするために、アクセストークンを発行します。
「Edit Profile > Access tokens」よりトークン名とスコープを指定します。Snowflake 側からの書き込み操作を試したかったため、簡単にスコープには「api」を指定しました。
トークン発行後、値を控えておきます。
Snowflaka 側でオブジェクトを作成
最後に、これまでの設定を使用し、Snowflake 側で Git リポジトリとの連携設定を行います。
基本的な流れは以下の記事と変わりません。PrivateLink を使用する設定が入ってきます。
オブジェクト格納用データベース・スキーマ、ロールの作成
はじめに以下の手順でオブジェクト格納用データベース・スキーマ、ロールを作成しました。
--データベース作成
USE ROLE sysadmin;
----シークレット管理用DB・スキーマを作成
CREATE DATABASE IF NOT EXISTS governance;
CREATE SCHEMA IF NOT EXISTS integrations;
--管理用ロールを作成
USE ROLE useradmin;
CREATE ROLE IF NOT EXISTS git_admin;
--スキーマに対するシークレットの作成権限を付与
USE ROLE securityadmin;
GRANT CREATE SECRET ON SCHEMA governance.integrations TO ROLE git_admin;
--対象のデータベース・スキーマに対するUSAGE権限も必要なので付与
GRANT USAGE ON DATABASE governance TO ROLE git_admin;
GRANT USAGE ON SCHEMA governance.integrations TO ROLE git_admin;
--ロール階層を定義
GRANT ROLE git_admin TO ROLE sysadmin;
--CREATE INTEGRATION 権限を付与
USE ROLE ACCOUNTADMIN;
GRANT CREATE INTEGRATION ON ACCOUNT TO ROLE git_admin;
API 統合の作成
HTTPS API を介してアクセスするサービスに関する情報を格納する API 統合オブジェクトを作成します。
ここでは以下のコマンドを使用しました。ポイントはUSE_PRIVATELINK_ENDPOINT = TRUEとしている箇所で、アウトバウンドプライベート接続を介し てリモート Git リポジトリへアクセスする際は、この設定が必要です。
--API統合を作成
USE ROLE git_admin;
USE SCHEMA governance.integrations;
CREATE OR REPLACE API INTEGRATION git_api_integration
API_PROVIDER = git_https_api
API_ALLOWED_PREFIXES = ('https://<GitLabのFQDN>')
ALLOWED_AUTHENTICATION_SECRETS = all
USE_PRIVATELINK_ENDPOINT = TRUE
ENABLED = TRUE;
シークレットの作成
アクセストークンなどの機密情報はシークレットオブジェクトに保存できます。これにより、他のSnowflake オブジェクトで安全に使用できるようになります。
ここでは、以下を実行し、先の手順で取得したアクセストークンを保存しました。
--コンテキストの設定（シークレット作成ロールに切り替え、スキーマを指定）
USE ROLE git_admin;
USE SCHEMA governance.integrations;
--シークレットを作成
CREATE OR REPLACE SECRET git_secret
TYPE = password
USERNAME = '<GitLab上のユーザー名>'
PASSWORD = '<トークン>';
リポジトリ ステージの作成
リポジトリステージとして、リモートリポジトリを Snowflake から読み取り可能なステージを作成します。ORIGIN に作成したリポジトリのURLを指定します。
--GIT REPOSITORY ステージを作成
CREATE OR REPLACE GIT REPOSITORY snowflake_extensions
API_INTEGRATION = git_api_integration
GIT_CREDENTIALS = git_secret
ORIGIN = 'https://<GitLabのFQDN>/testgroup/test-repo';
問題なく作成できると、Snowflake 側からも内容を確認できます。
ls @snowflake_extensions/branches/main;
プロジェクトに追加したREADMEを確認できます。
GitLab 側でプロジェクトにファイルを追加してみます。
リモートリポジトリに変更があり、その内容をリポジトリステージに反映するにはALTER GIT REPOSITORY コマンドを使用できます。
ALTER GIT REPOSITORY <リポジトリステージ名> FETCH;
更新後 Snowflake から確認すると、ファイルの追加を確認できます。
Workspace から書き込み操作を試す
執筆時点でプレビューの Workspace では Snowflake 側から変更（コミット、プッシュなど）も直接行えます。こちらを試してみます。
Git リポジトリから Workspace を作成
Workspace メニューの下図の箇所から「From Git repository」をクリックします。
下図の画面となるので、リポジトリの URL と接続情報（API 統合オブジェクト、アクセス方法）を指定します。
問題なければ Workspace を作成できます。同じリポジトリを同期しているので、先の手順で追加したファイルが表示されます。
基本操作を試してみる
ブランチの作成～mainブランチへのマージまでを試してみます。
ブランチを作成します。
下図の内容で SQL ファイルを作成しました。
Workspace からプッシュできます。
GitLab 側で確認します。
マージリクエストを作成し、main ブランチに変更を反映します。
問題なく一連の作業を行えました。
その後、先の手順で作成したリポジトリステージを更新し、内容を確認してみます。
ALTER GIT REPOSITORY snowflake_extensions FETCH;
ls @snowflake_extensions/branches/main;
同じリポジトリを参照しているので、こちらでも反映を確認できます。
SQL ファイルを実行し、オブジェクトをデプロイしてみます。
EXECUTE IMMEDIATE FROM @snowflake_extensions/branches/main/code/create-database.sql;
データベースを作成できました。
さいごに
GitLab のセルフホスト版を使用し、Snowflake からのアウトバウンドプライベート接続を試してみました。
Workspace の登場などもあり、Snowflake アカウントと リモート Git リポジトリの連携は増えていくと思います。セキュリティ要件上本構成が必要なケースもあるかと思いますので、こちらの内容が何かの参考になれば幸いです。
参考
