ユースケース
シナリオ：認証済みパートナーアクセスを持つフィンテックAPI
例示シナリオです。以下のチーム、インフラ、所要時間は例としての前提であり、実在する顧客の事例ではありません。
誰が：決済処理APIを運用する小規模なフィンテックチーム。 どこで：１台のVPS上の単一バックエンドサービス。 課題：TLS、DDoS対策、加盟店パートナー向けの認証済みAPIアクセスが必要だが、DevOpsエンジニアがおらず、Cloudflare、Auth0、APIゲートウェイを連携させるのに数週間をかけられない。
Secure Ingress導入前
デプロイには複数のサービスの設定と管理が必要：
５つのベンダー、５つの設定、５つの障害点、すべてが１つに。
ステップバイステップのデプロイ
1. 既存のAPIから始める
チームはすでにポート3000でリッスンする、コンテナ化されたNode.js APIを持っている：
# 既存のAPI、変更なし
node server.js # ポート3000でリッスン2. Consoleでプロジェクトとサービスアカウントを作成
チームはプロジェクト、本番環境、サービスアカウントを作成。サービスアカウントのAPIキーが、次のステップで使うWarpgateトークンになる。
3. Warpgateをサイドカーとして追加
# docker-compose.yml
services:
api:
build: .
# portsなし：APIはプライベートなComposeネットワーク内からのみ到達可能
warpgate:
image: mezusphere/warpgate
command: ["--api-key", "wg_prod_abc123...", "--upstream-url", "http://api:3000"]
depends_on:
- apiWarpgateは外向きにSecure Ingressに接続し、プライベートなComposeネットワーク経由でAPIに到達。APIはホストに公開されていないため、VPSにはAPI用のインバウンドポート、インバウンドのファイアウォールルール、公開リスナーは不要。チームは直接経路も閉じる。VPSを指していた旧来の公開リスナーとDNSレコードを削除し、APIへの唯一の経路をAltuur Edge経由にする。
4. Consoleでルートを設定
Secure Ingress Consoleでチームは以下を設定：
| ルート | パス | 認証要否 | 説明 |
|---|---|---|---|
| ヘルスチェック（公開） | /health | 不要 | 稼働状況監視 |
| 加盟店API | /api/v1/* | 必要 | 認証トークンが必要なパートナーエンドポイント |
| Webhookレシーバー | /webhooks/* | 不要 | 決済プロバイダーからのインバウンドWebhook |
5. パートナー認証を有効化
/api/v1/*ルートに対して、Consoleで認証を有効化：
- 「加盟店パートナー」というユーザーディレクトリを作成
- メール＋パスワード認証でパートナーアカウントを追加
/api/v1/*ルートに認証を要求
パートナーはログイン認証情報を受け取り、Altuurの認証フローでアクセストークンを取得。決済APIは事前認証済みのリクエストを受信；アプリケーションに認証コードは一切不要。
6. 公開
APIが本番環境のプラットフォーム提供ホスト名（例：https://payments-prod.mezusphere.io）で利用可能に。payments.example.comのようなカスタムドメインはロードマップ上の機能。トラフィックフロー：
TLS · 認証 · レート制限 · ルーティング
得られるもの
- TLS 1.3：自動、証明書管理不要
- レート制限とDDoS対策：エッジに組み込まれた不正利用対策とより広範なDDoS緩和、設定不要
- パートナー認証：Consoleで管理、アプリケーションコードはゼロ
- パスベースルーティング：公開ヘルスチェックと認証済みAPIを同じドメインで
- API用のインバウンドポートなし：ホストのファイアウォールをインバウンドに対して閉じたままにしておく限り、APIにはWarpgate経由でしか到達できない
- プラットフォームは１つ：単一のSecure Ingress設定が、個別のCloudflare、Auth0、APIゲートウェイ、証明書管理のセットアップを置き換え
デプロイにかかる作業
このシナリオでの変更は、Composeファイルの編集１回とConsoleでの数カ所の設定。チームはインフラ管理ではなく、決済機能の構築に時間を使える。
シナリオ：ステージング環境を持つマルチリージョンSaaS
例示シナリオです。以下のチーム、インフラ、所要時間は例としての前提であり、実在する顧客の事例ではありません。
誰が：Reactフロントエンドと３つのバックエンドマイクロサービスを持つB2B SaaSチーム。 どこで：レイテンシのためにAWS（us-east-1）とGCP（asia-northeast1）に分散。 課題：リージョンごと・環境ごと（dev、staging、prod）に異なるCloudflare設定、nginx ingressコントローラー、OAuth統合を管理することで、維持が困難な設定マトリックスが生まれている。
Secure Ingress導入前
環境×リージョンの各組み合わせにそれぞれ必要：
- Ingressコントローラー設定
- TLS証明書管理
- OAuthクライアント認証情報
- ファイアウォール/セキュリティグループルール
- DNSレコード
２リージョン×３環境で6以上の設定を同期する必要があり、それぞれ異なる認証情報とわずかに異なるセットアップが存在。
Secure Ingressの場合
1. サービスごと・環境ごとにWarpgateをデプロイ
各マイクロサービスに環境ごとのトークンを持つWarpgateサイドカーを追加：
# Kubernetesサイドカー（本番、us-east-1）
- name: warpgate
image: mezusphere/warpgate
args: ["--api-key", "wg_prod_useast_...", "--upstream-url", "http://localhost:8080"]# Kubernetesサイドカー（ステージング、asia-northeast1）
- name: warpgate
image: mezusphere/warpgate
args: ["--api-key", "wg_staging_apne1_...", "--upstream-url", "http://localhost:8080"]2. Consoleで統一ルーティング
すべての環境とリージョンを１つのConsoleから管理：
| 環境 | リージョン | エンドポイント | サービス |
|---|---|---|---|
| 本番 | us-east-1 | app-prod.mezusphere.io | フロントエンド、API、課金 |
| 本番 | asia-northeast1 | app-prod.mezusphere.io | フロントエンド、API |
| ステージング | us-east-1 | app-staging.mezusphere.io | フロントエンド、API、課金 |
各環境はプラットフォーム提供のホスト名を使用。app.example.comのようなカスタムドメインはロードマップ上の機能。ルート、認証ルール、権限は一度設定するだけで、リージョン間で一貫して適用。
3. 変わること
- Ingressコントローラー：不要に。Warpgateが置き換え。
- TLS証明書：自動。cert-managerもLet’s Encryptのcronジョブも不要。
- 環境ごとのOAuth：ConsoleでAuth設定を１つ管理。リージョンごとの個別OAuthクライアントは不要。
- ファイアウォールルール：これらのサービスにインバウンドポートは不要。旧来のインバウンドルールを削除すれば、セキュリティグループは極めてシンプルに。
- DNS管理：Secure Ingressがプラットフォーム提供のホスト名でエッジルーティングを処理。エンドポイントごとにCNAME１つのカスタムドメインはロードマップ上の機能。
結果
このシナリオでは、Ingressコントローラー、cert-manager、リージョンごとのOAuth設定ブロックがKubernetesマニフェストから消える。新しいリージョンの追加は、Warpgateサイドカー付きでサービスをデプロイし、Consoleで環境を作成するだけ。多数のコンポーネントにまたがるインフラプロジェクトが、小さな作業になる。