Warpgate
Warpgateは、ワークロードをAltuur Secure Ingressに接続する軽量サイドカーエージェントです。反転イングレスモデルを実装しています。インバウンドポートを開放してファイアウォールを設定する代わりに、WarpgateはAltuurのグローバルエッジに対して外側に接続します。
仕組み
- Warpgateがワークロードと一緒に起動
- AltuurのグローバルエッジへのアウトバウンドTLS 1.3接続を開始
- サービスアカウントAPIキーで認証
- Secure Ingressがこの確立されたトンネルを通じてエンドユーザートラフィックを転送
- 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で反射 | 無効 |
--name | Consoleに表示される名前 | ホスト名 |
--upstream-timeout | アップストリームのリクエストタイムアウト(秒) | 30 |
--upstream-health-path | アップストリームのヘルスチェックパス(例:/healthz)。未設定で無効 | 未設定 |
--metrics-addr | ローカルPrometheus /metricsエンドポイントのhost:port。空で無効 | 無効 |
--cert-dir | ブートストラップしたアイデンティティを再起動を跨いで永続化するディレクトリ | /var/lib/mezusphere/warpgate |
--probe-addr | liveness/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設定は不要です。
| 方向 | ポート | プロトコル | 目的 |
|---|---|---|---|
| アウトバウンド | 443 | TLS 1.3 | Altuur 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には何も送信されません。