Workload Identity Federationの仕組みを理解する

#Snowflake

Snowflakeの新しい認証方式であるWorkload Identity Federationは既に使っていますでしょうか？

私自身、業務で利用する機会がありとても便利だなと感じています。

Workload Identity FederationにはGetCallerIdentityベースとGetWebIdentityTokenベースの2つの方式があります。

それぞれの方式についてどう違うのか、どちらが良いのかなどがあまり理解できていなかったので、これを機に仕組みについて調べてみました。

目次

Workload Identity Federation（WIF）とは？

  • Snowflakeのサービスユーザーが利用可能な認証方法のうちの1つ
  • Snowflakeがホストされているクラウドプロバイダー（AWS, GCP, Azure）の認証サービスを利用した認証方法
  • OIDCのIDトークンを利用しているため、認証情報の有効期限が短い

サービスユーザーの認証方式はこれまでキーペア/OAuth/PATが選択肢としてあり、初回のセットアップやシークレットの管理など運用面が手間な部分がありました。

クラウドプロバイダーが必要ではあるものの、WIFを利用するメリットはかなりあると思います。

GetCallerIdentityベースとGetWebIdentityTokenベース

AWSの認証サービスを利用する場合、WIFには2種類の方法が利用でき、GetCallerIdentityベースとGetWebIdentityTokenのJWTベースのアプローチがあります。

1. GetCallerIdentityベース

クライアントはGetCallerIdentityで取得した認証情報を元に署名済みリクエストをSnowflakeへ送信し、Snowflake側が署名の正当性を検証します。

認証フローとしては以下のイメージです。

  1. GetCallerIdentityで取得した認証情報を元に署名(SigV4)済みリクエスト作成
  2. 作成したリクエストの文字列をトークンとしてSnowflakeに送信
  3. Snowflake側は受信したトークンを復元
  4. 中身の署名済みリクエストをそのままAWS STSに投げる
  5. 返却されたARNがSnowflakeサービスユーザーに登録されているARNと一致するか検証
  6. 一致すればセッショントークンをクライアントに発行する

1~2までのフローはsnowflake-connector-pythonの実装内容（Github）からも読み取ることができます。

3~6までのフローはSnowflake内部のフローなのであくまでイメージです。

2. GetWebIdentityTokenベース

クライアント自身がGetWebIdentityToken APIを使って署名済みJWTを取得し、それをSnowflakeに送信します。Snowflake側は登録されたサービスユーザーのWIF設定と照合する方法です。

この場合、利用するにはAWS IAM Outbound ID Federationの有効化が必要です。

認証フローとしては以下のイメージです。

  1. クライアントがGetWebIdentityToken APIを利用して署名済みJWTを取得し、Snowflakeに送信
  2. Snowflake側はAWS IAM Outbound ID Federationのトークン発行者URLを元に署名済みJWTを検証
  3. JWTのsubクレームをSnowflakeサービスユーザーに設定したARNと照合
  4. 一致すればセッショントークンをクライアントに発行する

GetCallerIdentityベースと同様に、1のフローはsnowflake-connector-pythonの実装内容（Github）からも読み取ることができます。

2~4までのフローはSnowflake内部のフローなのであくまでイメージですが、おそらくAWSブログで紹介されているトークン検証方法に近い方法なのではないかと思っています。

どちらを採用すべき？

ドキュメントにはJWT-basedの方法を推奨と記載があるのでGetWebIdentityTokenベースを採用するのが良さそうです。

Upgrade to JWT-based authentication (recommended)

出典：Workload identity federation | Snowflake Documentation

GetWebIdentityTokenベースを利用するメリットは以下です。

Snowflake側での検証時にAWS STSへの通信頻度が減る

GetWebIdentityToken方式では、公開鍵(JWKS)をキャッシュできるため、毎回AWS STSへの通信は発生しません。一方、GetCallerIdentity方式の場合は、AWS STSへの通信が毎回発生してしまいます。

IAMポリシーによるガバナンス制御が効く

GetWebIdentityToken方式ではIAMポリシーの条件キー（IdentityTokenAudience、DurationSeconds）による細かい設定が可能です。GetCallerIdentity方式では、このような細かい制御はできません。

最後に

SnowflakeのWorkload Identity Federationにおける2つの方式の認証フローを見てきました。

WIFの認証方式を理解することで、なぜJWT-basedの方が推奨されているのかわかった気がします。

クラウドプロバイダーからSnowflakeへ接続しているケースは認証方式をWIFにするのもアリですね。

最後まで読んでくださってありがとうございました。

参考