ワークロードIDフェデレーション¶
このドキュメントは以下を対象としています。
社内クラウドサービスの開発者。
内部および外部サービスとの統合を管理する管理者。
自分のプラットフォームで実行されている個々のワークロードに OpenID Connect(OIDC)フェデレーション ID トークンを発行することで、各顧客のワークロードがSnowflakeに専用ユーザーとして認証されるようにしたいマルチテナント SaaS アプリケーションの開発者。
ワークロードIDフェデレーション(WIF)は、アプリケーション、サービス、コンテナなどのワークロードが、AWS Identity and Access Management (AWS IAM) ロール、Microsoft Entra ID、Google Cloud サービスアカウントなどのクラウドプロバイダーのネイティブIDシステムを使用し、Snowflakeが使用して検証できる証明情報を取得することで、Snowflakeに対して認証を行うサービス間の認証メソッドです。
WIF により、パスワードなどの長期間有効な認証情報や、Snowflakeを認証するための API キー、キーペア、およびプログラムアクセストークンを管理および保存する必要がなくなります。また、WIF は、認証情報の取得に関連する複雑さを軽減します。他のメソッド(外部 OAuth など)では、設定により多くの作業が必要になる場合があります。Snowflakeコネクタを使用するアプリケーション、サービス、およびコンテナは、各プラットフォームのネイティブメカニズムを通じてプラットフォームのIDプロバイダー(IdP)から有効期限が短い認証情報を自動的に取得します。
利点¶
このセクションでは、認証に WIF を使用する理由について説明します。
費用対効果:既存の IdPs を使用してサービスIDを管理する場合、追加のツールやライセンスが不要になり、費用対効果が高くなります。
相互運用性:AWS IAM、Entra ID、Google Cloud などの人気のあるクラウドプロバイダーサービスは、外部ワークロードの認証メソッドとして WIF をサポートし、推奨しています。
便利な監査と監視:
管理者は、AWS CloudTrail および Azureモニター などの既存のクラウドプロバイダーサービスを利用して、アクティビティをログ記録および監視できます。
Snowflake管理者は、WIF を使用するサービスを監視および監査するため、ACCOUNT_USAGE スキーマ 内の LOGIN_HISTORY および CREDENTIALS ビューをクエリできます。
ワークロードIDフェデレーションを実装するためのワークフロー¶
WIF により、各種の IdPs を使用してさまざまなワークロードを認証することができますが、次のステップに示すように、基本的なワークフローは同じです。
ワークロード管理者として、ネイティブIDプロバイダーを使用するようにサービスを構成することで、プロバイダーがワークロードのIDの*証明書*を発行できるようにします。この証明書は、多くの場合 JSON ウェブトークン(JWT)ですが、必ずそうとは限りません。
Snowflake管理者として、ワークロード用にSnowflakeサービスユーザーを作成します。このユーザーのプロパティを、プロバイダーから送信された証明書に含まれる値に設定します。たとえば、ユーザープロパティで IAM ロールの名前やプロバイダーの発行者 URL を指定します。
ワークロード開発者として、Snowflake ドライバー を使用するようにワークロードを構成します。ドライバーは、確認のために証明書をSnowflakeに送信します。
各種のワークロードと IdPs に関する、このワークフローのエンドツーエンドの例を確認するには、ユースケース をご参照ください。
アクセス制御の要件¶
WIF をSnowflakeサービスユーザー(つまり、TYPE プロパティが SERVICE に設定されたユーザー)に対して構成するには、アクティブ化されたロールに次のいずれかの権限を付与する必要があります。
サービスユーザーについての OWNERSHIP。
サービスユーザーについての MODIFY PROGRAMMATIC AUTHENTICATION METHODS。
サポートされているSnowflakeドライバー¶
ワークロードは、Snowflakeに接続するときに、Snowflakeドライバーを使用して証明書を送信します。次のドライバーは、ワークロードIDフェデレーションをサポートしています。
ドライバー |
最小バージョン |
|---|---|
v1.16.0 |
|
v3.26.0 |
|
v4.8.0 |
|
v2.2.0 |
|
v3.11.0 |
|
v3.17.0 |
Snowflake IDの数の最小化¶
WIF ワークロードごとに専用のSnowflakeユーザーを作成することは、大規模になると困難になる可能性があります。複数のワークロードが、明確に定義された限られた数のSnowflakeサービスユーザーで認証するように、統合する方が良い場合が多くあります。このアプローチは、SnowflakeでIDの散布を減らし、ユーザーのライフサイクル管理を簡素化し、Snowflakeユーザーを個々のワークロードやインフラストラクチャに密接に結び付けることなく、一貫したアクセスパターンを可能にします。
複数のワークロード用に単一のユーザーを作成する¶
一部のクラウドプロバイダーでは、ワークロードに添付されたIDが別のIDを偽装できる場合があります。たとえば、Google Cloud上のワークロードがサービスアカウント A に添付されているとします。サービスアカウントの偽装 を使用して、サービスアカウント A がサービスアカウント B として認証されるようにすることができます。つまり、サービスアカウント A がサービスアカウント B を偽装し、ワークロードがユーザー B としてSnowflakeに認証できるようにします。
偽装は、多くのワークロードがある環境で特に役立ちます。各ワークロードとSnowflakeサービスユーザーの間に1対1のマッピングを作成すると、運用コストが高く管理が困難になるためです。複数のワークロードが共有されたSnowflake IDになりすますことができるようにすることで、チームはSnowflakeアクセスを少数のサービスユーザーに集中させながら、クラウドプロバイダーの IAM を通じてアクセス制御を実施できます。
前提条件
偽装を使用して複数のワークロードが単一のSnowflake IDで認証されるようにするには、ワークロードがGoogle Cloudまたは AWS 上にある必要があります。現在、Microsoft Azureは偽装をサポートしていません。
ワークフロー
ワークロード管理者として、ワークロードを構成し、添付されたIDが別のIDを偽装するようにします。
Snowflake管理者として、Snowflakeに認証するクラウドプロバイダーIDに対応するサービスユーザーを作成します。たとえば、ワークロードがサービスアカウント
Dを使用して認証している場合は、サービスユーザーを作成し、その SUBJECT パラメーターをサービスアカウントDの一意の識別子に設定します。ワークロード開発者として、ドライバーの接続パラメーターを使用し、偽装を使用するワークロードのIDチェーンを定義します。パラメーターは文字列のリストに設定されます。各文字列はクラウドプロバイダーのID(例:サービスアカウント ID)です。
ドライバーは、次のクラウドプロバイダーIDの承認に必要なトークンを取得するために、リストで定義されたIDチェーンに従います。チェーン内の各IDは、次のIDを偽装する権限のみを必要とします。リストの最後のIDは、Snowflakeへの接続に使用されるSnowflake接続トークンを取得します。
ドライバーの接続パラメーターの構文を取得するには、ドライバーのドキュメントをご参照ください。
例
Google Cloudワークロードがサービスアカウント A にアタッチされているが、サービスアカウント B を偽装し、そのサービスアカウントがさらにサービスアカウント D を偽装しているとします。ワークロードがサービスアカウント D のIDを使用して WIF に対して認証するようにPythonドライバーをセットアップするには、次のように接続パラメーターを定義します。
workload_identity_impersonation_path=['service_account_a@my-project.iam.gserviceaccount.com',
'service_account_b@my-project.iam.gserviceaccount.com',
'service_account_d@my-project.iam.gserviceaccount.com']
ワークロード用に作成されたSnowflakeサービスユーザーには、IDチェーンの最終的なIDの識別子が含まれている必要があります。上記の例に基づいて、以下のコマンドでサービスユーザーを作成します。
CREATE USER <username>
WORKLOAD_IDENTITY = (
TYPE = GCP
SUBJECT = 'service_account_d@my-project.iam.gserviceaccount.com'
)
TYPE = SERVICE
DEFAULT_ROLE = PUBLIC;
複数の GitHub または GitLab 環境用に単一のユーザーを作成する¶
GitHub のアクションまたは GitLab のプロジェクトを使用している場合は、ツールの OIDC プロバイダーを使用して、WIF でSnowflakeに対して認証できます。デフォルトでは、各 GitHub アクションまたは GitLab プロジェクトの OIDC トークンは、sub クレーム内のサブジェクトが異なる場合があり、その場合、各サブジェクトに1つずつ、複数のSnowflakeサービスユーザーが必要になります。
ただし、GitHub および GitLab では、OIDC トークンの sub クレームをカスタマイズできます。これにより、すべての環境で OIDC トークンのサブジェクトが同じになるようにツールを構成できます。Snowflakeサービスユーザーを作成するときは、GitHub または GitLab から受信する OIDC トークンのサブジェクトを指定します。トークンのサブジェクトは常に同じ(つまり、カスタム値)であるため、すべての環境に対して1つのサービスユーザーのみが必要です。
GitHub または GitLab OIDC トークンの sub クレームのカスタマイズの詳細については、以下のリソースをご参照ください。
GitHub:組織またはリポジトリのサブジェクトクレームをカスタマイズするには、GitHub のドキュメント をご参照ください。
GitLab:プロジェクト API を使用して GitLabOIDC トークンの
subクレームをカスタマイズするには、GitLab のドキュメント をご参照ください。現在、クレームはci_id_token_sub_claim_components属性でカスタマイズされています。
カスタムの sub クレームを定義し、それがすべての GitHub または GitLab 環境で同一になるようにした後、Snowflakeサービスユーザーの SUBJECT パラメーターをカスタムの sub クレームに一致するように設定します。
セキュリティ体制の強化¶
認証ポリシー を使用すると、WIF で認証できるSnowflakeサービスユーザーを制御できます。認証ポリシーを作成して設定することで、ワークロードが指定されたIDプロバイダーまたはそのプロバイダー内のアカウントを使用する場合にのみ、認証できるようにすることもできます。
たとえば、次の認証ポリシーでは、ワークロードがプロバイダーとして Microsoft Entra ID を使用し、証明書の発行者がテナント ID が https://login.microsoftonline.com/9ebd1ec9-9a78-4429-8f53-5cf870a812d1/v2.0 である Microsoft Entra ID テナントである場合にのみ認証できます。
CREATE AUTHENTICATION POLICY workload_policy WORKLOAD_IDENTITY_POLICY=( ALLOWED_PROVIDERS = (AZURE) ALLOWED_AZURE_ISSUERS = ( 'https://login.microsoftonline.com/9ebd1ec9-9a78-4429-8f53-5cf870a812d1/v2.0') );
WORKLOAD_IDENTITY_POLICY パラメーターの詳細については、CREATE AUTHENTICATION POLICY をご参照ください。
認証ポリシーを設定して適用する方法の詳細については、アカウントまたはユーザーに認証ポリシーを設定する をご参照ください。
ユースケース¶
次のユースケースは、ワークロードに対して WIF を実装する例です。
AWS IAM ロールとSnowflake Pythonドライバーを使用して認証する¶
WIF を使用して AWS サービスからSnowflakeに認証するには、次のタスクを実行します。
AWS を構成する¶
AWS サービスが AWS IAM をIDプロバイダーとして使用するように構成するには、IAM ロールをアタッチします。詳細については、ワークロードに対応する AWS ドキュメントをご参照ください。
Amazon EC2 については、インスタンスへの IAM ロールのアタッチ をご参照ください。
AWS Lambdaについては、実行ロールを使用したLambda関数のアクセス許可の定義 をご参照ください。
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、Snowflakeへの認証インスタンスに関連付けられたAWSユーザーまたはロールを一意に識別するAmazon Resource Identifier(ARN)を指定します。IAM ロールの ARN を取得するため、次のステップを完了します。
AWS コンソールにサインインしてから、IAM ダッシュボードに移動します。
左側のナビゲーションで、Roles を選択します。
AWS インスタンスにアタッチしたロールの名前を選択します。
Summary セクションで、ARN を見つけ、Copy アイコンを選択します。
Snowflakeは、次の IAM 識別子 形式を受け入れます。
arn:aws:iam::account:user/user_name_with_path
arn:aws:iam::account:role/role_name_with_path
arn:aws:sts::account:assumed-role/role_name/role_session_name
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER <username> WORKLOAD_IDENTITY = ( TYPE = AWS ARN = '<amazon_resource_identifier>' ) TYPE = SERVICE DEFAULT_ROLE = PUBLIC;
ここでは、
ARNは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
import os import snowflake.connector conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='AWS' )
Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
Microsoft Entra ID とSnowflake Pythonドライバーを使用して認証する¶
Microsoft Entra ID からSnowflakeに対して WIF を使用して認証するには、以下に示す各セクションのステップを完了してください。
Microsoft Entra ID を構成する¶
Microsoft Entra ID テナント管理者は、SnowflakeワークロードIDの使用を許可するために、以下のステップを完了する必要があります。これらの手順は Microsoft Entra ID テナントごとに1回実行するだけで済みます。
Microsoft Azure ポータルにログインします。
間違いなく Azure テナント管理者権限があることを確認します。
同意 URI に移動し、マルチテナント Snowflake EntraID アプリのインストールに同意します。
マルチテナントSnowflake EntraID アプリはパブリッシャー確認済みで、Snowflakeをリソースとして表します。このアプリは、Snowflakeでの認証時に、アクセストークンのオーディエンスとして使用されます。このアプリは基本的な権限のみを必要とし、特権は必要ありません。
Accept を選択して、Snowflake EntraID アプリに権限を付与します。
Microsoft Azure を構成する¶
次のステップを完了して、Microsoft Azure サービスが WIF を使用するように構成します。
Microsoft Azure ポータルにログインします。
サイドバーで、Security » Identity に移動します。
Azure VM または Azure Function のマネージドIDを有効にします。
後のステップのために Object (Principal) ID を保存します。
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、次の情報が必要です。
大文字と小文字を区別する、前のステップ で有効にしたマネージドIDのオブジェクト ID (プリンシパル ID)。この識別子は、Azure Portal を使用してAzure VM または Function の Identity ページからコピーできます。
Microsoft Entraテナント ID。この値を使用して、認証機関 URL を構築します。
Microsoft Entra Consoleを使用してテナント ID を取得するには、Microsoft Entraテナント ID を検索する方法 をご参照ください。
PowerShell を使用してテナント ID を取得するには、次のコマンドを実行します。
Connect-AzAccount Get-AzTenant
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER <username> WORKLOAD_IDENTITY = ( TYPE = AZURE ISSUER = 'https://login.microsoftonline.com/<tenant_id>/v2.0' SUBJECT = '<managed_identity_object_id>' ) TYPE = SERVICE DEFAULT_ROLE = PUBLIC;
ここでは、
ISSUERおよびSUBJECTは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
import snowflake.connector conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='AZURE' )
Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
注釈
ワークロードの開発者は、ワークロード管理者が有効にしたマネージドIDに関連する環境変数を設定する必要がある場合があります。管理者が システム割り当てマネージドIDではなく ユーザー割り当てマネージドID を有効にした場合、MANAGED_IDENTITY_CLIENT_ID 環境変数をSnowflakeでの認証に使用するマネージドIDのクライアント ID に設定する必要があります。
Google Cloud サービスアカウントとSnowflake Pythonドライバーを使用して認証する¶
WIF を使用して Google Cloud サービスからSnowflakeに認証するには、次のタスクを実行します。
Google Cloud を構成する¶
サービスが Google Cloud をIDプロバイダーとして使用するように構成するには、サービスアカウントを GCE またはCloud Runインスタンス にアタッチします。
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、サービスアカウントの uniqueId プロパティの値が必要です。この一意の ID を取得するには、Google Cloud CLI を使用して次のコマンドを実行します。
gcloud iam service-accounts describe "<SERVICE_ACCOUNT_EMAIL_ADDRESS>" --format="value(uniqueId)"
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER <username> WORKLOAD_IDENTITY = ( TYPE = GCP SUBJECT = '<unique_id_of_service_account>' ) TYPE = SERVICE DEFAULT_ROLE = PUBLIC;
ここでは、
SUBJECTは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
import snowflake.connector conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='GCP' )
Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
Elastic Kubernetes Service (EKS) の OpenID Connect(OIDC)発行者を使用して認証する¶
Elastic Kubernetes Service (EKS) からSnowflakeに対して WIF を使用して認証するには、以下に示す各セクションのステップを完了してください。
EKS を構成する¶
Snowflake と互換性のある ID トークンを発行するように EKS を構成します。
snowflakecomputing.comというオーディエンスクレームを含む ID トークンを構成します。以下は、適切なオーディエンスによる YAML 構成の例です。
kind: Pod metadata: name: nginx spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /var/run/secrets/tokens name: snowflake-token serviceAccountName: build-robot volumes: - name: snowflake-token projected: sources: - serviceAccountToken: path: snowflake-token expirationSeconds: 7200 audience: snowflakecomputing.com
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、次の情報が必要です。
Kubernetesサービスアカウント用に ID トークンを生成している OIDC プロバイダーの発行者 URL。この発行者 URL を取得するには、次のタスクのいずれかを実行します。
クラスターの Overview タブに移動し、OpenID Connect provider URL フィールドの値をコピーします。
API サーバーエンドポイントにアクセスできる状態で、次のコマンドを実行します。
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
Kubernetesサービスアカウントの名前空間と名前。この情報を使用して、OIDC プロバイダーが発行した ID トークンのサブジェクトを構築します。
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER my_eks_service WORKLOAD_IDENTITY = ( TYPE = OIDC ISSUER = 'https://oidc.eks.<region>.amazonaws.com/id/<issuer_id>' SUBJECT = 'system:serviceaccount:<service_account_namespace>:<service_account_name>' ) TYPE = SERVICE;
ここでは、
ISSUERおよびSUBJECTは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='OIDC', token_file_path='<service_account_token_path>' )
ここでは、
service_account_token_pathは、EKS を構成する ステップで作成したものです。このステップの YAML の例に基づくと、トークンパスは/var/run/secrets/tokens/snowflake-tokenになります。Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
Azure Kubernetes Service (AKS) の OpenID Connect(OIDC)発行者を使用して認証する¶
Azure Kubernetes Service (AKS) からSnowflakeに対して WIF を使用して認証するには、以下に示す各セクションのステップを完了してください。
AKS を構成する¶
Snowflake と互換性のある ID トークンを発行するように AKS を構成します。
Snowflake と互換性のある ID トークンを発行するように AKS を構成します。
snowflakecomputing.comというオーディエンスクレームを含む ID トークンを構成します。以下は、適切なオーディエンスによる YAML 構成の例です。
kind: Pod metadata: name: nginx spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /var/run/secrets/tokens name: snowflake-token serviceAccountName: build-robot volumes: - name: snowflake-token projected: sources: - serviceAccountToken: path: snowflake-token expirationSeconds: 7200 audience: snowflakecomputing.com
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、次の情報が必要です。
Kubernetesサービスアカウント用に ID トークンを生成している OIDC プロバイダーの発行者 URL。この発行者 URL を取得するには、Microsoft のドキュメント をご参照ください。
Kubernetesサービスアカウントの名前空間と名前。この情報を使用して、OIDC プロバイダーが発行した ID トークンのサブジェクトを構築します。
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER my_aks_service WORKLOAD_IDENTITY = ( TYPE = OIDC ISSUER = 'https://<region>.oic.prod-aks.azure.com/<tenant_id>/<uuid>/' SUBJECT = 'system:serviceaccount:<service_account_namespace>:<service_account_name>' ) TYPE = SERVICE;
ここでは、
ISSUERおよびSUBJECTは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='OIDC', token_file_path='<service_account_token_path>' )
ここでは、
service_account_token_pathは、AKS を構成する ステップで作成したものです。このステップの YAML の例に基づくと、トークンパスは/var/run/secrets/tokens/snowflake-tokenになります。Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
Google Kubernetes Engine (GKE) の OpenID Connect(OIDC)発行者を使用して認証する¶
Google Kubernetes Engine (GKE) からSnowflakeに対して WIF を使用して認証するには、以下に示す各セクションのステップを完了してください。
GKE を構成する¶
Snowflake と互換性のある ID トークンを発行するように GKE を構成します。
snowflakecomputing.comというオーディエンスクレームを含む ID トークンを構成します。以下は、適切なオーディエンスによる YAML 構成の例です。
kind: Pod metadata: name: nginx spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /var/run/secrets/tokens name: snowflake-token serviceAccountName: build-robot volumes: - name: snowflake-token projected: sources: - serviceAccountToken: path: snowflake-token expirationSeconds: 7200 audience: snowflakecomputing.com
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、次の情報が必要です。
その Google Cloud プロジェクト ID、クラスターのリージョン、クラスター名。この情報を使用して、OIDC 発行者を構築します。
Kubernetesサービスアカウントの名前空間と名前。この情報を使用して、OIDC プロバイダーが発行した ID トークンのサブジェクトを構築します。
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER my_gke_service WORKLOAD_IDENTITY = ( TYPE = OIDC ISSUER = 'https://container.googleapis.com/v1/projects/<project_id>/locations/<region>/clusters/<cluster_name>' SUBJECT = 'system:serviceaccount:<service_account_namespace>:<service_account_name>' ) TYPE = SERVICE;
ここでは、
ISSUERおよびSUBJECTは、これらのステップを開始する前に取得した値です。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='OIDC', token_file_path='<service_account_token_path>' )
ここでは、
service_account_token_pathは、GKE を構成する ステップで作成したものです。このステップの YAML の例に基づくと、トークンパスは/var/run/secrets/tokens/snowflake-tokenになります。Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
カスタム OpenID Connect(OIDC)プロバイダーを使用して認証する¶
以下にリストされている各セクションのステップを完了し、カスタム OIDC プロバイダーからSnowflakeに対して WIF を使用して認証します。
OIDC プロバイダーの構成¶
Discovery仕様内で指定されているとおりに、間違いなく OIDC プロバイダーが`OpenID Configuration <https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig>`_ をサポートしていることを確認します。構成と構成の
jwks_uriエンドポイントの両方がパブリックにアクセス可能である必要があります。OpenID プロバイダーが、
snowflakecomputing.comまたは空でないカスタムリストに設定されたオーディエンスクレームを含む ID トークンを発行するように構成します。空でないカスタムリストを定義する場合は、Snowflakeでサービスユーザーを作成するときに指定する必要があります。
Snowflakeの構成¶
Snowflakeを構成するには、Snowflakeに対して WIF を使用して認証する、タイプ SERVICE のユーザー、すなわちSnowflakeサービスユーザーを作成します。
始める前に
Snowflakeを正常に構成するには、次の情報が必要です。
OIDC プロバイダーの発行者 URL。
ワークロードに関連するサブジェクトクレーム。
これらの値はいずれも、ワークロード用に発行された ID トークンの iss クレームと sub クレームを解析することで取得できます。たとえば、Unixライクな環境に jq、cat、echo でアクセスできる場合、ID トークンをファイルに保存して、次のコマンドで実行することができます。
ID_TOKEN_PATH=<id_token_path>
JWS_PAYLOAD=$(cat $ID_TOKEN_PATH | jq -R 'split(".") | .[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson')
echo "ISSUER = '$(echo $JWS_PAYLOAD | jq -r .iss)'"
echo "SUBJECT = '$(echo $JWS_PAYLOAD | jq -r .sub)'"
ID を取得する方法については、OIDC プロバイダーのドキュメントをご参照ください。
ワークロードのサービスユーザーを作成するには:
Snowsight にサインインします。
ワークシートのリストを開くには、ナビゲーションメニューで :ui:`Projects`|raa|:ui:`Worksheets`を選択します。
新しい SQL ワークシートを開くには、+ を選択します。
Snowflakeに対して WIF を使用して認証するサービスユーザーを作成するには、次のワークシートで CREATE USER ステートメントを実行します。
CREATE USER my_custom_service WORKLOAD_IDENTITY = ( TYPE = OIDC ISSUER = '<issuer>' SUBJECT = '<subject>' OIDC_AUDIENCE_LIST = ('<custom_audience>') ) TYPE = SERVICE;
条件:
ISSUERおよびSUBJECTは、これらのステップを開始する前に取得した値です。OIDC_AUDIENCE_LISTは、OIDC プロバイダーの構成 で設定された ID トークンのオーディエンスクレームの空でないスーパーセットです。ID トークンのオーディエンスクレームがsnowflakecomputing.comの場合、OIDC_AUDIENCE_LISTを指定する必要はありません。
Snowflakeドライバーを使用するようにワークロードを構成する¶
注釈
ワークロードを構成して、WIF をサポートする任意のSnowflakeドライバーを使用できるようにすることができます。完全なリストについては、 サポートされているSnowflakeドライバー をご参照ください。
ワークロードにPythonドライバーが必要な場合は、以下のステップを完了します。
Pythonアプリケーションコードに、以下のソースコードを追加します。
conn = snowflake.connector.connect( account='<snowflake_account>', authenticator='WORKLOAD_IDENTITY', workload_identity_provider='OIDC', token='<id_token>' )
ここでは、
id_tokenは、ワークロードの OIDC プロバイダーから受信した期限切れの ID トークンです。このトークンを取得する方法については、OIDC プロバイダーのドキュメントをご参照ください。Pythonアプリケーションを実行します。WIF を使用してSnowflakeに認証します。
サービスユーザーの設定を見る¶
SHOW USER WORKLOAD IDENTITY AUTHENTICATION METHODS コマンドを実行し、サービスユーザーの WORKLOAD_IDENTITY パラメーターの値を表示します。たとえば、サービスユーザー my_custom_service がSnowflakeへの認証に使用する WIF 設定を表示するには、次のコマンドを実行します。
SHOW USER WORKLOAD IDENTITY AUTHENTICATION METHODS FOR USER my_custom_service;
制限と考慮事項¶
Azureワークロードは、Azure中国、Azure US 政府などのAzureソブリンクラウドに配置することはできません。この制限は、アカウントのSnowflakeリージョンに関連していません。