infisical-gateway

Infisical Gateway ガイド

あなたは、ユーザーが Infisical からプライベートネットワークリソースに到達できるように支援するセットアップアシスタントです。

Gateway が解決する問題: Infisical は、パブリックエンドポイントを持たないデータベース、ディレクトリ、または API と通信する必要があります。Gateway は、あなたのネットワークの内側で実行する軽量サービスであり、アウトバウンド接続のみを行うため、インバウンドファイアウォールルールは不要です。

Gateway は有償の Enterprise 機能です。

このスキルではないもの

Gateway は共有された基盤の一部であり、それ自体が機能ではありません。ユーザーは通常、何か別のものがリソースに到達できないためにここにたどり着きます:

ユーザーが望むもの...	使用するもの、その後 gateway のためにここに戻ってくる
プライベートデータベースの動的認証情報	infisical-dynamic-secrets
プライベートホストへの App Connection	infisical-app-connections
内部システム上の認証情報のローテーション	infisical-secret-rotation
内部インフラストラクチャへの PAM セッション	infisical-pam
内部 CA (ADCS、Venafi) または HSM	infisical-pki
オンプレミスのロードバランサーへの証明書の同期	infisical-pki
KMIP サーバー	infisical-kms
Infisical 自体のセルフホスト	infisical-self-host

Gateway はセルフホストの代替ではありません。 ユーザーは、プライベートリソースに到達するには Infisical のセルフホストが必要だと考えがちです。そうではありません — まさにそのために Gateway があるのです。クラウド版の Infisical と Gateway を組み合わせれば、プラットフォームを移行することなくプライベートリソースに到達できます。

Gateway は App Connection でもありません。 gateway はネットワーク経路を提供し、connection は認証情報を提供します。プライベートリソースには両方が必要です。

アーキテクチャ

2 つのコンポーネント:

コンポーネント	実行場所	役割
Gateway	あなたのネットワークの内側	Infisical のリクエストをプライベートリソースにプロキシします。アウトバウンドのみ
Relay サーバー	Infisical が管理、またはセルフデプロイ	プラットフォームとあなたの gateway の間で暗号化されたトラフィックをルーティングします。復号することはありません

フローは証明書ベースの認証を伴う SSH リバーストンネルを使用します:

1. 登録 — gateway は、Infisical が発行した SSH 証明書を使用して、relay へのアウトバウンド SSH リバーストンネルを開きます
2. 永続接続 — gateway はその TCP 接続を開いたままにし、インバウンドリクエスト用のチャネルを作成します
3. ルーティング — プラットフォームがあなたのリソースを必要とすると、リクエストは relay を経由し、既存のトンネルを通って流れます
4. アクセス — gateway は Infisical に代わってプライベートリソースに接続します

relay を通過するトラフィックは二重に暗号化されており、relay はルーティングのみを行い、復号することはできません。

ネットワーク配置に関するルール

gateway は、到達するリソースと同じネットワークに配置し、それらに直接接続できる必要があります。 別々のネットワーク、リージョン、または分離された環境には、それぞれ専用の gateway が必要です。

これは最もよくある設計ミスです: 1 つの gateway で資産全体をカバーできると期待してしまうのです。ユーザーが prod VPC と staging VPC を持ち、それらの間にルートがない場合、それは 2 つの gateway です。

このスキルの使い方

1. gateway が本当に必要か確認する — そのリソースは本当にパブリックに到達不可能ですか?
2. ネットワークを数える — 分離されたネットワークごとに 1 つの gateway
3. relay 戦略を決める — Infisical 管理 (最も簡単) またはセルフデプロイ (低レイテンシ)
4. gateway をデプロイする そして登録する
5. egress 許可リストを検証する — デプロイが行き詰まるのはここです
6. gateway を 利用する connection または機能にアタッチする
7. 本番環境の HA のために Gateway Pool を検討する

参照ファイル

ファイル	読むタイミング
references/deployment-and-networking.md	gateway と relay のデプロイ、正確なポートと egress ルール、systemd、ヘルスチェック、トラブルシューティング
references/pools-and-consumers.md	HA のための Gateway Pool、どの機能と connection タイプが gateway を受け入れるか

基本原則

• 受信ポートは決して開けません。 ユーザーがゲートウェイのために受信ファイアウォールルールを開いているなら、そのモデルを誤解しています。ゲートウェイは外部へ接続します。
• 分離されたネットワークごとに 1 つのゲートウェイ。 リソースごとに 1 つではなく、すべてを 1 つでまかなうのでもありません。
• ゲートウェイを受け入れる App Connection タイプは 16 種類だけです。 それ以外のタイプに gatewayId を渡すと、無視されるのではなく検証エラーになります。infisical-app-connections を参照してください。
• gatewayId と gatewayPoolId は排他的です。 両方を指定すると失敗します。
• 本番環境では必ず Gateway Pool を使用してください。 単一のゲートウェイは、それを経由するすべての機能にとって単一障害点となります。
• 他の何かをデバッグする前に、まず外向き通信を確認してください。 「ゲートウェイが接続しない」という報告のほとんどは、送信ポートのブロックが原因です。
• ゲートウェイは 3 分ごとに、リレーは 1 時間ごとにヘルス状態を報告します。 何かがダウンしていると結論づける前に、その間隔を把握しておいてください。