Snowpark Container Services: サービスのその他の考慮事項¶

Snowflakeへの接続¶

コンテナからSnowflakeに接続するには、2つの方法があります。

• （推奨）Snowflakeが提供する OAuth トークンを使用します。サービスユーザーとして（または、呼び出し元権限も使用する場合は呼び出しユーザーとして）接続を確立します。このオプションはすべてのサービスで機能し、追加の権限を必要としません。ただし、クライアントコードで使用されるSnowflakeホスト名を構成する必要があります。

• サービスがSnowflakeのインターネットエンドポイントに接続できるようにする、外部アクセス統合を使用します。これにより、Snowflakeが提供する OAuth トークンだけでなく、任意のSnowflake認証情報を使用できます。ただし、このオプションでは、管理者が外部アクセス統合を作成し、サービス所有者ロールに統合に対する USAGE 権限を付与する必要があります。

SNOWFLAKE_ACCOUNT = os.getenv('SNOWFLAKE_ACCOUNT')
SNOWFLAKE_HOST = os.getenv('SNOWFLAKE_HOST')

def get_login_token():
  with open('/snowflake/session/token', 'r') as f:
    return f.read()

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth'
)

conn = snowflake.connector.connect(
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  user = '<user-name>',
  password = '<password>'
)

SQL を実行するためのデータベースとスキーマコンテキストを設定します。¶

このセクションでは、2つの概念について説明します。

• サービスを作成するデータベースとスキーマを決定するためにSnowflakeが使用するロジック。

• Snowflakeがこの情報をコンテナーに伝え、コンテナーコードが同じデータベースとスキーマコンテキストで SQL を実行できるようにするためのメソッド。

Snowflakeはサービス名を使用して、サービスを作成するデータベースとスキーマを決定します。

• 例1: 以下の CREATE SERVICE および EXECUTE JOB SERVICE コマンドでは、サービス名が明示的にデータベース名とスキーマ名を指定していません。Snowflakeは、現在のデータベースとスキーマでサービスとジョブサービスを作成します。

  -- Create a service.
  CREATE SERVICE test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = example_job_service ...
  

  Copy

• 例2: 以下の CREATE SERVICE と EXECUTE JOB SERVICE コマンドでは、サービス名にデータベース名とスキーマ名が含まれています。Snowflakeは、現在のスキーマに関係なく、指定されたデータベース（test_db）とスキーマ（test_schema）にサービスとジョブサービスを作成します。

  -- Create a service.
  CREATE SERVICE test_db.test_schema.test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = test_db.test_schema.example_job_service ...
  

  Copy

Snowflakeがサービスを開始する際は、以下の環境変数を使用して、実行中のコンテナにデータベースとスキーマ情報が提供されます。

• SNOWFLAKE_DATABASE

• SNOWFLAKE_SCHEMA

コンテナーコードでは、この例に示すように、接続コードで環境変数を使用して、使用するデータベースとスキーマを決定することができます。

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth',
  database = os.getenv('SNOWFLAKE_DATABASE'),
  schema = os.getenv('SNOWFLAKE_SCHEMA')
)

例

チュートリアル2 では、Snowflakeに接続して SQL ステートメントを実行するSnowflakeジョブサービスを作成します。以下のステップは、チュートリアルのコードがどのように環境変数を使用するかをまとめたものです。

1. 共通セットアップ（共通セットアップ セクションを参照）では、データベースとスキーマを含む、リソースを作成します。また、セッションの現在のデータベースとスキーマも設定します。

   USE DATABASE tutorial_db;
   ...
   USE SCHEMA data_schema;
   

   Copy

2. （EXECUTE JOB SERVICE を実行して）ジョブサービスを作成すると、Snowflakeはコンテナを起動し、コンテナ内の以下の環境変数をセッションの現在のデータベースとスキーマに設定します。

   • SNOWFLAKE_DATABASE は「TUTORIAL_DB」に設定

   • SNOWFLAKE_SCHEMA は「DATA_SCHEMA」に設定

3. ジョブコード（チュートリアル2の main.py を参照）はこれらの環境変数を読み取ります。

   SNOWFLAKE_DATABASE = os.getenv('SNOWFLAKE_DATABASE')
   SNOWFLAKE_SCHEMA = os.getenv('SNOWFLAKE_SCHEMA')
   

   Copy

4. ジョブコードは SQL ステートメント（main.py の run_job() 関数）を実行するコンテキストとしてデータベースとスキーマを設定します。

   {
      "account": SNOWFLAKE_ACCOUNT,
      "host": SNOWFLAKE_HOST,
      "authenticator": "oauth",
      "token": get_login_token(),
      "warehouse": SNOWFLAKE_WAREHOUSE,
      "database": SNOWFLAKE_DATABASE,
      "schema": SNOWFLAKE_SCHEMA
   }
   ...
   

   Copy

   注釈

   SNOWFLAKE_ACCOUNT、SNOWFLAKE_HOST、 SNOWFLAKE_DATABASE、 SNOWFLAKE_SCHEMA はSnowflakeがアプリケーションコンテナー用に生成する環境変数ですが、 SNOWFLAKE_WAREHOUSE はそうではありません（Snowflakeはウェアハウス名をコンテナーに渡さないため、チュートリアル2のアプリケーションコードがこの変数を作成しました）。

コンテナー用ウェアハウスの指定¶

サービスがSnowflakeに接続してSnowflakeウェアハウスでクエリを実行する場合は、ウェアハウスを指定する以下のオプションがあります。

• アプリケーションコードでウェアハウスを指定します。 コードでクエリを実行するためにSnowflakeセッションを開始する際に、接続構成の一部としてウェアハウスを指定します。例については、 チュートリアル2 をご参照ください。

• Specify a default warehouse when creating a service. Specify the optional QUERY_WAREHOUSE parameter in the CREATE SERVICE or EXECUTE JOB SERVICE command to provide a default warehouse. If your application code doesn't provide a warehouse as part of connection configuration, Snowflake uses the default warehouse. Use the ALTER SERVICE command to change the default warehouse.

  注釈

  The warehouse specified using the QUERY_WAREHOUSE parameter is the default only for the service user. When the service connects to Snowflake on behalf of another user --- in the context of caller's rights scenario, Snowflake uses the user's default warehouse.

If you specify a warehouse by using both methods, the warehouse that is specified in the application code is used.

SQL を実行するための OAuth トークンの使用¶

Snowflakeが提供するすべてのクライアントは、認証方法として OAuth をサポートしています。サービスコンテナも OAuth メカニズムを使用してSnowflakeで認証を行います。たとえば、コンテナーが SQL を実行する場合、コンテナーは他のSnowflakeクライアントと同様にSnowflakeへの接続を作成します。

def get_login_token():
  with open('/snowflake/session/token', 'r') as f:
    return f.read()

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth'
)

サービスを作成すると、Snowflakeはコンテナを実行し、コンテナ内の /snowflake/session/token にコンテナが使用するOauthトークンを提供します。

この OAuth トークンについては、次の点に注意してください。

• Snowflakeは、 /snowflake/session/token ファイルの内容を数分ごとに更新します。トークンの有効期限は1時間です。コンテナーがSnowflakeに正常に接続した後には、有効期限は接続に適用されません（ユーザーが直接作成するセッションと同様）。

• この OAuth トークンは、特定のSnowflakeサービス内でのみ有効です。OAuth トークンをコピーしてサービス外部で使用することはできません。

• コンテナは、 OAuth トークンを使ってサービスユーザーとしてSnowflakeに接続し、サービスの所有者ロールを使用します。

• OAuth トークンを使用して接続すると、新しいセッションが作成されます。OAuth トークンはいずれの既存の SQL セッションとも関連付けられていません。

  注釈

  ストアドプロシージャの実行とサービスの実行の大きな違いは、ストアドプロシージャはそれを実行する SQL と同じセッションで実行されることです。しかし、コンテナーが新しい接続を確立するたびに、新しいセッションが作成されます。

Connections to Snowflake from inside a container by using caller's rights¶

Containers execute queries by connecting to Snowflake as the service user and using the service's owner role that grants privileges to the service. In certain application scenarios, you might need to execute queries by using the context of the end user rather than the service user. The caller's right feature is used in this context.

For example, suppose you create a service that exposes a public endpoint to provide a web application that displays a dashboard that uses data stored in Snowflake. You grant other users in your Snowflake account access to the dashboard by granting the service role to those users. When any one of these users signs in to the dashboard, you want the dashboard to display only the data the user has access to.

However, because containers by default execute queries by using the service user and the service's owner role, the dashboard shows the data that the service's owner role has access to, regardless of which end user connected to the endpoint. As a result, the data in the user's dashboard isn't limited to what the end user has access to. This allows the user to access data that they shouldn't be allowed to access.

To limit the dashboard to show only data accessible to the signed in user, the application containers must execute SQL by using privileges granted to the end user. You can enable this by using caller's rights in the application.

ALTER USER my_user SET DEFAULT_SECONDARY_ROLES = ( 'ALL' );

-- Permissions to resolve the table's name.
GRANT CALLER USAGE ON DATABASE <db_name> TO ROLE <service_owner_role>;
GRANT CALLER USAGE ON SCHEMA <schema_name> TO ROLE <service_owner_role>;
-- Permissions to use a warehouse
GRANT CALLER USAGE ON WAREHOUSE <warehouse_name> TO ROLE <service_owner_role>;
-- Permissions to query the table.
GRANT CALLER SELECT ON TABLE T1 TO ROLE <service_owner_role>;

サービスクエリ履歴へのアクセス¶

user_type が SNOWFLAKE_SERVICE である場合、 QUERY_HISTORY ビュー または QUERY_HISTORY 関数をフィルターすることで、サービスによって実行されたクエリを見つけることができます。

例1: サービスによって実行されるフェッチクエリ。

SELECT *
FROM snowflake.account_usage.query_history
WHERE user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
AND user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
order by start_time;

WHERE 句で、

• user_name = '<service_name>': サービスは サービスユーザー としてクエリを実行し、サービスユーザーの名前はサービス名と同じであるため、ユーザー名としてサービス名を指定します。

• user_type = 'SNOWFLAKE_SERVICE' および user_name = '<service_name>': これはクエリ結果を、あるサービスによって実行されたクエリのみを取得するように制限します。

• user_database_name および user_schema_name: サービスユーザーにとって、これらはサービスのデータベースとスキーマです。

QUERY_HISTORY 関数を呼び出しても同じ結果が得られます。

SELECT *
FROM TABLE(<service_db_name>.information_schema.query_history())
WHERE user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
AND user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
order by start_time;

WHERE 句で、

• user_type = 'SNOWFLAKE_SERVICE' および user_name = '<service_name>' は、あるサービスによって実行されたクエリのみを取得するようにクエリ結果を制限します。

• user_database_name と user_schema_name の名前は、サービスユーザーの場合、サービスのデータベースとスキーマです。

例2: サービスによって実行されたクエリと対応するサービス情報を取得します。

SELECT query_history.*, services.*
FROM snowflake.account_usage.query_history
JOIN snowflake.account_usage.services
ON query_history.user_name = services.service_name
AND query_history.user_schema_id = services.service_schema_id
AND query_history.user_type = 'SNOWFLAKE_SERVICE'

このクエリは、 QUERY_HISTORY と SERVICES ビューを結合し、クエリとクエリを実行したサービスに関する情報を取得します。次の点に注意してください。

• サービスによって実行されるクエリの場合、 query_history.user_name は、サービスユーザー名です。これは、サービス名と同じです。

• クエリは、スキーマ IDs （スキーマ名ではない）を使用してビューを結合し、同じスキーマを参照していることを確認します。スキーマをドロップして再作成すると、スキーマ ID は変更されますが、名前は同じままだからです。

クエリにオプションのフィルターを追加することができます。例:

• 特定のクエリを実行したサービスのみを取得するためのフィルター query_history。

• 特定のサービスによって実行されたクエリのみを取得するためのフィルター services。

例3: すべてのサービスについて、サービスユーザー情報をフェッチします。

SELECT services.*, users.*
FROM snowflake.account_usage.users
JOIN snowflake.account_usage.services
ON users.name = services.service_name
AND users.schema_id = services.service_schema_id
AND users.type = 'SNOWFLAKE_SERVICE'

このクエリは、 ACCOUNT_USAGE スキーマの SERVICES と USERS ビューを結合し、サービスとサービスユーザー情報を取得します。次の点に注意してください。

• サービスがクエリを実行すると、サービスユーザーとしてクエリを実行します。サービスユーザーの名前はサービス名と同じです。したがって、結合条件 users.name = services.service_name を指定します。

• サービス名はスキーマ内でのみ一意です。したがって、クエリは、各サービスユーザーが所属する固有のサービス（そして、異なるスキーマで実行されている他の同じ名前のサービスではない）に対して一致することを確実にするために、結合条件（users.schema_id = services.service_schema_id）を指定します。

Google Cloudでのファイルステージングコマンドのサポート¶

Google CloudでSnowflakeクライアントライブラリを使用して PUT、 GET、 LIST、または REMOVE コマンドを使用するには、クライアントを少なくとも次のバージョンに更新します。

イングレス接続のタイムアウト¶

イングレスエンドポイントのタイムアウトは90秒です。イングレスエンドポイントへの接続に90秒間アクティビティがない場合、Snowflakeは接続を終了します。アプリケーションでもっと長く接続する必要がある場合は、ポーリングまたは WebSockets を使用します。

イングレスウェブブラウザー認証ログアウト¶

サービスとして動作するウェブアプリを構築している場合、ユーザーを /sfc-endpoint/logout に誘導してアプリからログアウトできるようにするオプションがあります。

ログアウト後、ユーザーはサービスのパブリックエンドポイントにアクセスするためにSnowflakeへの再認証が必要となります。

イングレスとウェブアプリのセキュリティ¶

パブリックエンドポイントサポート（ネットワークイングレス）を使用して、ウェブホスティング用のSnowpark Container Servicesサービスを作成できます。セキュリティを強化するために、Snowflakeはプロキシサービスを採用して、クライアントからサービスへの受信リクエストと、サービスからクライアントへの送信応答をモニターします。このセクションでは、プロキシが何を行い、Snowpark Container Servicesに展開されたサービスにどのような影響を与えるかを説明します。

例:

• 禁止されている HTTP メソッドをリクエストが使用する場合、プロキシは受信 HTTP リクエストを転送しません。

• プロキシは、応答のContent-Typeヘッダーが実行可能ファイルを含むことを示す場合は、403応答をクライアントに送信します。

さらに、プロキシはリクエストと応答に新しいヘッダーを注入したり、既存のヘッダーを変更したりすることもできます。

たとえば、リクエストを受信すると、サービスは応答で HTML、 JavaScript、 CSS などのウェブページのコンテンツをクライアントのブラウザーに送信する可能性があります。ブラウザー上のウェブページはサービスの一部であり、ユーザーインターフェイスとして機能します。セキュリティ上の理由から、サービスに制限がある場合（他サイトへのネットワーク接続の制限など）に、サービスのウェブページにも同じ制限を設けたい場合があります。

デフォルトでは、サービスはインターネットにアクセスする権限が制限されている。ブラウザーでも、クライアントアプリがインターネットにアクセスし、データを共有する可能性を制限する必要があります。外部アクセス統合（EAI）を設定してサービスが example.com （ネットワークエグレスの構成 を参照）にアクセスできるようにすると、サービスのウェブページもブラウザーを通して example.com にアクセスできるようになります。

Snowflakeプロキシは、応答に Content-Security-Policy （CSP）ヘッダーを追加して、サービスとウェブページに同じネットワーク制限を適用します。デフォルトでは、プロキシは一般的なセキュリティの脅威から守るために、応答にベースライン CSP を追加します。ブラウザーのセキュリティは、機能性とセキュリティのバランスをとるためのベストエフォートであり、このベースラインがあなたのユースケースに適切であることを確認することは、共有された責任です。さらに、サービスが EAI を使用するように設定されている場合、プロキシはウェブページに対して EAI から CSP まで同じネットワークルールを適用します。この CSP により、ブラウザーのウェブページは、サービスがアクセスできるのと同じサイトにアクセスできるようになります。

Snowflakeは、サービス仕様で構成する CORS サポートを提供します。

Snowflakeプロキシは、サービス仕様で定義されている CORS 設定を返します。プロキシはサービスによって返された CORS ヘッダーをすべて削除することに注意してください。

以下の CORS ヘッダーはデフォルトでセットされています。

• Access-Control-Expose-Headers ヘッダーは、エンドポイントのサービス仕様で構成されたヘッダーに加えて、常に以下のヘッダー名を報告します。

  • X-Frame-Options

  • Cross-Origin-Opener-Policy

  • Cross-Origin-Resource-Policy

  • X-Content-Type-Options

  • Cross-Origin-Embedder-Policy

  • Content-Security-Policy-Report-Only

  • Content-Security-Policy

• Access-Control-Max-Age は2時間にセットされます。

• Access-Control-Allow-Credentials はtrueにセットされます。

さらに、Snowflakeは、 Origin の値に基づいて、 Access-Control-Allow-Origin の値が異なる可能性があることをブラウザーに示すために、 Origin の値で Vary ヘッダーをセットします。

CORS リクエストを実行するには、 Authorization ヘッダーが必要です。このヘッダー（Authorization: "Snowflake Token=\"${patToken}\""）にプログラムによるアクセストークン（PAT）を指定できます。プログラムのアクセストークンを生成する方法については、 認証のためのプログラム アクセス トークンの使用 をご参照ください。

以下のセクションでは、Snowflakeプロキシがサービスに対する受信リクエストをどのように処理し、サービスからクライアントへの送信応答をどのように変更するかを説明します。

進入と CORS への配慮¶

デフォルトでは、ブラウザーは、あるサーバーでホストされているウェブアプリが、ホスト名の異なる別のサーバーにリクエストを送信するのをブロックします。例えば、Snowpark Container Services内にデプロイされたバックエンドサービスとやり取りする必要があるウェブアプリをSnowpark Container Servicesの外でホストする場合、この制限が適用されます。

CORS （Cross-Origin Resource Sharing）により、Snowpark Container Servicesサービスは、その環境外でホストされているウェブアプリからのリクエストを許可するよう、ブラウザーに指示することができます。各パブリックエンドポイントを構成して、 CORS プリフライトリクエストと標準リクエストの両方への応答方法を指定できます。

Snowflakeプロキシは常に以下のレスポンスヘッダーを上書きします。

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

Snowflakeプロキシは、以下のいずれかが真である場合、レスポンスにこれらの CORS ヘッダーを含めません。

• CORS はサービスエンドポイントに構成されていません。つまり、サービス仕様に corsSettings はありません

• CORS がサービスエンドポイントに構成されていますが、リクエストの Origin ヘッダーがサービス仕様の指定された Access-Control-Allow-Origin フィールドと一致しません

サービス仕様では、各パブリックエンドポイントに対して CORS の設定を行うことができます。リクエストの origin ヘッダーが、仕様でエンドポイントに指定されている Access-Control-Allow-Origin フィールドにマッチするとき、プロキシは以下の調整を加えて、仕様で定義されている CORS ヘッダーをレスポンスに含めます。

• Access-Control-Allow-Origin: リクエストから Origin ヘッダーを返します。

• Access-Control-Expose-Headers: 構成した許可ヘッダーのリストを、これらの常時公開ヘッダーとマージします: X-Frame-Options、 Cross-Origin-Opener-Policy、 Cross-Origin-Resource-Policy、 X-Content-Type-Options、 Cross-Origin-Embedder-Policy、 Content-Security-Policy-Report-Only、 Content-Security-Policy。

• Access-Control-Max-Age:2時間にセットされます。

• Access-Control-Allow-Credentials: trueにセットされます。

進入と SSO への配慮¶

インターネットからパブリックエンドポイントにアクセスすると、ユーザー名/パスワード認証コードは機能しますが、 SSO では、空白のページが表示されるか、以下のエラーが表示されることがあります。「指定されたOAuth クライアントとの統合 ID が見つかりません。」

この現象は、 フェデレーション認証を使用するためのSnowflakeの構成 で説明されている新しいセキュリティ統合バージョンではなく、Snowflake で古いスタイルの統合認証 (SSO) を使用している場合に発生します。次のことを確認してください。

1. 以下のクエリを実行します。

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   このパラメーターがセットされている場合は、ある時点で旧式の認証コードを使用していたことになります。

2. 前述のパラメーターがセットされている場合、以下のクエリを実行して、 SAML セキュリティ統合があるかどうかを確認します。

   SHOW INTEGRATIONS
     ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
   

   Copy

   SAML2 タイプの統合がない場合は、旧式の認証コードを使用していることになります。

この大文字と小文字の場合、解決策は、旧式の統合認証から新しい統合形式の統合認証に移行することです。詳細については、 SAML2 セキュリティ統合への移行 をご参照ください。

プライベート接続を使用したネットワークエグレス¶

公衆インターネット経由でネットワークのイグレスをルーティングする代わりに、 プライベート接続エンドポイント を介してサービスのイグレス・トラフィックを誘導することを選択することもできます。

まず、Snowflakeアカウントでプライベート接続エンドポイントを作成する必要があります。次に、 プライベート接続 を使用する発信トラフィックを許可するネットワークルールを構成します。外部アクセス統合(EAI)のセットアップ手順は、前のセクションと同じです。

例えば、プライベート接続を介してAmazon S3バケットへのサービスのアウトバウンドインターネットアクセスを有効にしたい場合、次のようにします。

1. 自営エンドポイントサービス（Amazon S3）のプライベートリンク接続を有効にします。ステップバイステップの手順については、 AWS　Private Link for Amazon S3 をご参照ください。

2. SYSTEM$PROVISION_PRIVATELINK_ENDPOINT システム関数を呼び出して、Snowflake VNet にプライベート接続エンドポイントをプロビジョニングします。これにより、Snowflakeはプライベート接続を使用して外部サービス（この例ではAmazon S3）に接続できるようになります。

   USE ROLE ACCOUNTADMIN;
   
   SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
     'com.amazonaws.us-west-2.s3',
     '*.s3.us-west-2.amazonaws.com'
   );
   

   Copy

3. クラウドプロバイダーのアカウントで、エンドポイントを承認します。この例では、Amazon AWS の場合、 接続リクエストを受け入れるか拒否するか AWS ドキュメントの　 を参照してください。 また、Azure でエンドポイントを承認するには、 Azure ドキュメント をご参照ください。

4. CREATE NETWORK RULE コマンドを使用して、アクセスを許可する外部宛先を指定するエグレスネットワークルールを作成します。

   CREATE OR REPLACE NETWORK RULE private_link_network_rule
     MODE = EGRESS
     TYPE = PRIVATE_HOST_PORT
     VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
   

   Copy

   TYPE パラメーターの値は PRIVATE_HOST_PORT にセットされます。このネットワークルールは、発信ネットワークトラフィックが プライベート接続 を使用することを許可することを示します。

5. EAI を作成し、それを使用してサービスを作成する残りの手順は、前のセクションで説明したのと同様です（ネットワークエグレスの構成 を参照）。

プライベート接続エンドポイントの操作については、以下を参照してください。

• プライベート接続エンドポイントの管理: AWS

• プライベート接続エンドポイントの管理:Azure

• プライベート接続エンドポイントの管理: Google Cloud

Snowflakeのシークレットを指定する¶

Snowflakeのシークレットを名前または参照で指定します（参照はNative Applicationシナリオでのみ適用可能です）。

• Snowflake のシークレットを名前で渡す: snowflakeSecret フィールドの値としてシークレット名を渡すことができます。

  ...
  secrets:
  - snowflakeSecret:
      objectName: '<secret-name>'
    <other info about where in the container to copy the secret>
    ...
  

  Copy

  なお、 snowflakeSecret の値として、 <secret-name> を直接指定することもできます。

• Snowflakeシークレットをリファレンスで渡す: Snowpark Container Services を使用してNative App（コンテナー付きアプリ）を作成する場合、アプリのプロデューサーとコンシューマーは異なる Snowflake アカウントを使用します。場合によっては、インストールされた Snowflake Native Appは、 APPLICATION オブジェクトの外部に存在するコンシューマーカウントの既存のオブジェクトにアクセスする必要があります。この場合、開発者は「secrets by reference（参照によるシークレット）」指定構文を使用して、図のように認証情報を扱うことができます。

  containers:
  - name: main
    image: <url>
    secrets:
    - snowflakeSecret:
        objectReference: '<reference-name>'
      <other info about where in the container to copy the secret>
  

  Copy

  この仕様では、シークレットの参照名を提供するために、 objectName の代わりに objectReference を使用していることに注意してください。

コンテナー内のシークレットの配置を指定する¶

Snowflakeには、シークレットを環境変数としてコンテナーに配置するか、ローカルコンテナーファイルに書き込むように指示することができます。

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: <secret-name>
    secretKeyRef: username | password | secret_string |  'access_token'
    envVarName: '<env-variable-name>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: username
    envVarName: LOGIN_USER
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: password
    envVarName: LOGIN_PASSWORD

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    secretKeyRef: secret_string
    envVarName: GENERIC_SECRET

containers:
- name: <name>
  image: <url>
  ...
  secrets:
  - snowflakeSecret: <snowflake-secret-name>
    directoryPath: '<local directory path in the container>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.oauth_secret
  TYPE = OAUTH2
  OAUTH_REFRESH_TOKEN = '34n;vods4nQsdg09wee4qnfvadH'
  OAUTH_REFRESH_TOKEN_EXPIRY_TIME = '2023-12-31 20:00:00'
  API_AUTHENTICATION = my_integration;

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.oauth_secret
    directoryPath: '/usr/local/creds'