本文へスキップ

Warpgate

Warpgate(ワープゲート)は、ワークロードをAltuur Secure Ingress(アルトゥール セキュアイングレス)に接続する軽量サイドカーエージェントです。反転イングレスモデルを実装しています。インバウンドポートを開放してファイアウォールを設定する代わりに、Warpgate(ワープゲート)はAltuur(アルトゥール)のグローバルエッジに対して外側に接続します。

仕組み

  1. Warpgate(ワープゲート)がワークロードと一緒に起動
  2. AltuurのグローバルエッジへのアウトバウンドTLS 1.3接続を開始
  3. サービスアカウントAPIキーで認証
  4. Secure Ingress(セキュアイングレス)がこの確立されたトンネルを通じてエンドユーザートラフィックを転送
  5. Warpgate(ワープゲート)がプライベートなネットワーク経路でワークロードにトラフィックを渡す。Kubernetesポッド内ならlocalhost、Composeネットワークならサービス名、ホスト上のアプリなら隣のホスト

ワークロードはインターネットからのインバウンド接続を受け入れる必要がありません。オープンなインバウンドポート、インバウンドのファイアウォールルール、パブリックIPアドレスはいずれも不要です。ただし、Warpgate(ワープゲート)を追加しても既存の公開リスナーは消えないため、ワークロードへの直接経路は閉じるかファイアウォールで遮断してください(直接経路を閉じるを参照)。

デプロイオプション

まずサービスアカウントを作成します。Warpgate(ワープゲート)は、Console(コンソール)でプロジェクトのサービスアカウントから生成するAPIキーで認証します。以下の例では、そのキーのプレースホルダーとしてYOUR_API_KEYを使います。

Docker Compose

コンテナ化されたアプリケーションとWarpgate(ワープゲート)を一緒に動かす場合の推奨方法です。両者を同じComposeプロジェクトのサービスとして実行すると、Composeがプライベートネットワークを用意します。Warpgate(ワープゲート)はサービス名でアプリケーションに到達でき、アプリケーションにはports:の指定がないため、そのネットワークの内側からしか到達できません。

services:
  app:
    image: your-app:latest
    # portsなし:アプリはプライベートなComposeネットワーク内からのみ到達可能

  warpgate:
    image: mezusphere/warpgate
    command: ["--api-key", "YOUR_API_KEY", "--upstream-url", "http://app:8080"]
    depends_on:
      - app

ホスト上のアプリケーションに対してDockerを使用

アプリケーションがホスト上で直接動作している場合は、ホストをWarpgate(ワープゲート)コンテナから参照できるようにし、アップストリームをそこに向けます。コンテナ内のlocalhostはホストではなくコンテナ自身を指します。

docker run --add-host=host.docker.internal:host-gateway mezusphere/warpgate \
  --api-key YOUR_API_KEY \
  --upstream-url http://host.docker.internal:8080

この方法は、アプリケーションがホスト上でリッスンし、Dockerブリッジネットワークからの接続を受け付けること(たとえば0.0.0.0:8080にバインドする)、そしてそのポートが公開されていないことを前提とします。ホストのファイアウォールまたはクラウドのセキュリティグループでインターネットに対して閉じたままにし、Warpgate(ワープゲート)だけが到達できるようにしてください。

エコーモード

アップストリームを接続する前に、接続性を確認できます。--echoを付けると、Warpgate(ワープゲート)はエンドポイント経由のすべてのリクエストに、受け取ったリクエストの内容(メソッド、パス、ヘッダー、アイデンティティ)をJSONで反射して応答します。

docker run mezusphere/warpgate --api-key YOUR_API_KEY --echo

エンドポイント経由でエコー応答が返ってきたら、--echoを--upstream-urlに置き換えてサービスを指定してください。

mezusphere/warpgateイメージはマルチアーキテクチャ(linux/amd64、linux/arm64)で、arm64のエッジデバイスを含め、DockerまたはKubernetesが動く場所ならどこでも動作します。

Kubernetes

ポッドのサイドカーコンテナとしてWarpgate(ワープゲート)をデプロイ:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
        - name: app
          image: your-app:latest
          ports:
            - containerPort: 8080
        - name: warpgate
          image: mezusphere/warpgate
          args:
            - "--api-key"
            - "YOUR_API_KEY"
            - "--upstream-url"
            - "http://localhost:8080"

ポッド内のコンテナはネットワーク名前空間を共有するため、ここではlocalhostで正しく到達できます。containerPortはポートを記述するだけで、クラスター外に公開するものではありません。アプリケーション用のServiceやIngressは追加しないでください。Warpgate(ワープゲート)が唯一の入口です。

任意のKubernetesディストリビューションで動作:EKS、GKE、AKS、k3s、セルフマネージドクラスター。

直接経路を閉じる

Warpgate(ワープゲート)を追加しても、既存のパブリックIPアドレス、リスナー、ファイアウォールルールは消えません。ワークロードが以前からインターネットに到達可能だった場合は、公開していたポート、DNSレコード、セキュリティグループのルールを削除するか、信頼できるアドレスだけに制限し、ワークロードへの唯一の経路がAltuur(アルトゥール) Edge経由になるようにしてください。セキュリティで説明する分離の特性は、この作業を前提としています。

設定

コマンドラインフラグ

フラグ説明デフォルト
--api-key認証用サービスアカウントAPIキー必須
--upstream-urlワークロードのアドレス。--echo使用時は省略--echo以外では必須
--echoエコーモード:転送せずリクエスト内容をJSONで反射無効
--nameConsole(コンソール)に表示される名前ホスト名
--upstream-timeoutアップストリームのリクエストタイムアウト(秒)30
--upstream-health-pathアップストリームのヘルスチェックパス(例:/healthz)。未設定で無効未設定
--metrics-addrローカルPrometheus /metricsエンドポイントのhost:port。空で無効無効
--cert-dirブートストラップしたアイデンティティを再起動を跨いで永続化するディレクトリ/var/lib/mezusphere/warpgate
--probe-addrliveness/readinessプローブ用のhost:portデフォルトのプローブポート
--no-probesプローブサーバーを無効化(オーケストレーターなしのアドホック実行用)無効
--log-levelログの詳細度(debug、info、warn、error)info

環境変数

すべてのフラグは環境変数でも設定できます。フラグ名を大文字にしてアンダースコアでつなぎます(プレフィックスなし):

変数対応するフラグ
API_KEY--api-key
UPSTREAM_URL--upstream-url
ECHO--echo
NAME--name
UPSTREAM_TIMEOUT--upstream-timeout
UPSTREAM_HEALTH_PATH--upstream-health-path
METRICS_ADDR--metrics-addr
CERT_DIR--cert-dir
PROBE_ADDR--probe-addr
NO_PROBES--no-probes
LOG_LEVEL--log-level

接続性

アウトバウンド接続

Warpgate(ワープゲート)は、相互認証(mTLS)付きTLS 1.3を使用してAltuurのグローバルエッジへの永続的なアウトバウンド接続を確立します。接続は:

  • 暗号化:TLS 1.3、ダウングレードなし
  • 認証済み:サービスアカウント認証情報による相互TLS
  • 永続的:Warpgate(ワープゲート)プロセスのライフタイム中維持
  • 自動再接続:ネットワーク中断時にバックオフ付きで自動再接続

ネットワーク要件

Warpgate(ワープゲート)はアウトバウンドHTTPS接続のみ必要です。インバウンドポート、インバウンドのファイアウォールルール、VPN設定は不要です。

方向ポートプロトコル目的
アウトバウンド443TLS 1.3Altuur Edgeへの接続

クラウド非依存

Warpgate(ワープゲート)はワークロードがどこで動作していても同一に動作します:

  • AWS(EC2、ECS、EKS、Lambda)
  • Google Cloud(GCE、GKE、Cloud Run)
  • Azure(VM、AKS、Container Instances)
  • オンプレミスデータセンター
  • ローカル開発マシン
  • エッジデバイス(Raspberry Pi、IoT)

デプロイパターンは常に同じ:ワークロードと一緒にWarpgate(ワープゲート)を実行し、トークンを提供し、アップストリームを指定。

リソース使用量

Warpgate(ワープゲート)は軽量に設計されています:

  • 最小限のコンテナイメージ(mezusphere/warpgate)に収めた単一の静的バイナリ
  • 最小限のメモリフットプリント
  • 無視できるCPUオーバーヘッド
  • ログ以外のディスクI/Oなし

プロキシでも、サービスメッシュコントロールプレーンでも、テレメトリを送信するエージェントでもありません。接続先は、上で説明したアウトバウンドトンネルとコントロールプレーンセッションだけです。

お客様自身のモニタリングのために、Warpgate(ワープゲート)はローカルのPrometheus /metricsエンドポイントを公開できます。リクエストレート、レイテンシ、サイズ、アップストリームの健全性、トンネル再接続といった標準的なリバースプロキシメトリクスです。デフォルトでは無効(--metrics-addrで有効化)で、Secure Ingress(セキュアイングレス)には何も送信されません。