Data Contract CLIでSnowflakeとKeyPair認証で接続する
背景
データのスキーマは様々な理由で変更されることがあり、データオーナー側はその変更の影響範囲を正確に把握することは難しいことが多いです。そのため、複数のデータオーナーと安全にソースデータを連携するために、新規ソースデータの連携方法を明確化する必要があり、近年、ソースデータのスキーマ情報の管理やソースデータ監視などの仕組みの必要性が重要視されてきています。
そこで、Data Contractという概念を取り入れることで、ソースデータのスキーマ情報やサービスレベルの管理を安全かつスムーズに運用できないか検討していました。
Data Contractでは、データの送り手(データ提供者)と受け手(データ消費者)の間で連携するデータのスキーマ情報を明示的に定義し、その定義を遵守することで連携するソースデータに関する契約を結ぶ概念です。(身近な類似している例としては、APIの共有する際に使用するOpenAPI Specification(Swagger)が近い。)
Data Contractを実際に実現するために、今回はData Contract Specificationで提示されているデータ仕様を採用しました。Data Contract Specificationは、Data Contractを開発、検証、実施するためのオープン ソース ツールであるData Contract CLIをサポートしています(下記、Data Contract CLIの活用例)
検証を進めていく中で、Data Contract CLIからSnowflakeに接続する必要がありましたが、Data Contract Specification記事の中にはUser/Passwordによる認証しか記載がなくKeyPair認証による接続のやり方で迷いました。Snowflakeは2025年11月までにサービスユーザーを含む全てのユーザーの単一要素パスワード認証をブロックすることを発表しており、Data Contract CLIを継続して使用するためにKeyPair認証でのData Contract CLIの利用は不可避だと思うので、本記事にその解決策を残しておきます。
解決策
結論
環境変数に下記を設定することで、KeyPair認証でSnowflakeに接続ができました。
export DATACONTRACT_SNOWFLAKE_PRIVATE_KEY_PATH="<private_key_file_path>"
または
export DATACONTRACT_SNOWFLAKE_PRIVATE_KEY="<private_key>"
調査したこと
Data Contract CLIのソースコードを確認すると、Data Contract CLIでは、SodaCoreを利用してデータのバリデーションが実行されていました。
SodaCoreのドキュメントを確認すると、KeyPair認証でSnowflakeと認証するオプションが用意されています。( https://docs.soda.io/soda/connect-snowflake.html )
Data Contract CLIからどう設定すればいいか、改めてSoda Parameterを作成している箇所を確認すると、下記のようにSodaCoreに注入するParameterを作成していました。
なので、DATACONTRACT_SNOWFLAKE_**
のように環境変数を設定したら、注入されそう。ということで、下記のように環境変数を設定し、無事Data Contract CLIでSnowflakeとKeyPair認証で接続することができました。
export DATACONTRACT_SNOWFLAKE_PRIVATE_KEY_PATH="<private_key_file_path>"
終わりに
Data Contract CLIは実際の運用する際にはまだ課題がありそうですが、Data Contractを運用することで、データ提供者とデータ消費者の間でのボトルネックを解消し、より安全でスムーズなデータ品質管理が実現できそうです。今後も引き続き、Data Contract CLIを利用したプラクティスなど模索していけたらと思います。
Discussion