コアコンセプト
このページでは、Altuur Secure Ingressの主要なエンティティと抽象化について説明します。これらのコンセプトを理解することで、ワークロードの整理とトラフィックルーティングの設定を効果的に行えます。
組織（Organization）
Secure Ingressの最上位エンティティです。組織はプロジェクト、課金、チームアクセスをグループ化します。Secure Ingressのすべてのものは組織に属します。
組織は通常、会社ごとに１つです。チームメンバーは組織レベルで招待され、課金は単一の組織アカウントに統合されます。
プロジェクト（Project）
組織の下にある、環境、ルート、Warpgate、サービスアカウントの論理的なグループです。プロジェクトは、Secure Ingressを通じて公開する単一のサービスまたはアプリケーションを表します。
例：Webアプリケーションと別のAPIサービスがある場合、それぞれに１つずつ、２つのプロジェクトを作成します。
各プロジェクトには以下があります：
- １つ以上の環境（本番、ステージング、開発）
- トラフィックがワークロードに到達する方法を定義するルート
- Warpgate認証用のサービスアカウント
- エンドユーザー管理用のユーザーディレクトリ（認証が有効な場合）
環境（Environment）
プロジェクト内の名前付きデプロイターゲットです。各環境には独自のエンドポイントURLがあり、独立して有効/無効にできます。
一般的な環境：
- 本番（Production）：エンドユーザーからのライブトラフィック
- ステージング（Staging）：本番に近い設定でのリリース前テスト
- 開発（Development）：ローカル開発とデバッグ
環境は分離されています。ルート、Warpgate接続、認証設定は環境ごとに独立して設定されます。
ルート（Route）
プロジェクト内のURLパスルーティングルールです。ルートは、受信リクエストがワークロードにどのように振り分けられるかを決定します。
Secure Ingressは３つのマッチングモードをサポートしています：
| モード | 説明 | 例 |
|---|---|---|
| Prefix | 指定された値で始まるパスにマッチ | /api/は/api/users、/api/ordersにマッチ |
| Exact | パスが完全に一致 | /healthは/healthのみにマッチ |
| Regexp | 正規表現でマッチ | /users/[0-9]+は/users/123にマッチ |
ルートは以下で設定できます：
- 認証要件：特定のルートでログインを要求
- パーミッション要件：特定のロールを持つユーザーにアクセスを制限
- CORS設定：ルートごとのクロスオリジンリソース共有を設定
Warpgate
ワークロードと一緒にデプロイされる軽量サイドカーです。WarpgateはAltuurのグローバルエッジに対して外側に接続し、エンドユーザーのトラフィックがワークロードに転送されるセキュアなトンネルを確立します。
主な特徴：
- アウトバウンド接続：Warpgateがすべての接続を開始。インバウンドポート不要
- 自動登録：Warpgateはサービスアカウント認証情報を使用してコントロールプレーンに自動登録
- ステータス追跡：各Warpgateは接続ステータス（connected、disconnected、unknown）とIPアドレスを報告
- 自己登録型：WarpgateはConsoleからは作成できない。デプロイ時に自動登録
サービスアカウント（Service Account）
Warpgate登録とAPIアクセスに使用されるマシン認証情報です。各サービスアカウントには以下があります：
- APIキー：サーバー側で生成される50文字のbase62文字列
- 設定可能なパーミッション：サービスアカウントがアクセスできるものを制御
- プロジェクトスコープ：サービスアカウントは単一のプロジェクトにスコープ
Warpgateをデプロイする際、認証トークンとしてサービスアカウントAPIキーを提供します。Warpgateはこのキーを使用してSecure Ingressに自動登録します。
アーキテクチャ
Secure Ingressのアーキテクチャは２つのプレーンで構成されています：
データプレーン
データプレーンはエンドユーザーと顧客ワークロード間のライブトラフィックを処理します。以下で構成されます：
- グローバルエッジノード：TLSを終端し、認証・認可ポリシーを適用し、悪意のあるトラフィックをフィルタリングし、リクエストを正しいWarpgateにルーティングするパブリックに到達可能なポイント
- Warpgate：顧客ワークロードと一緒にデプロイされ、エッジノードへの永続的なTLS 1.3トンネルを維持するアウトバウンドコネクタ
トラフィックフロー：エンドユーザーはHTTPS経由でエッジノードに接続します。エッジノードがリクエストを認証し、ルーティングとセキュリティポリシーを適用した後、承認されたトラフィックを確立されたトンネルを通じてWarpgateに転送し、Warpgateがローカルワークロードに配信します。
コントロールプレーン
コントロールプレーンは設定、アイデンティティ、運用状態を管理します。以下を提供します：
- 設定管理：プロジェクト、環境、ルート、ポリシー
- アイデンティティサービス：ユーザーディレクトリ、認証フロー、サービスアカウント認証情報
- Warpgate登録：サービスアカウント認証、証明書発行、設定配布
- 運用データ：メトリクス、ログ、課金情報
Warpgateは起動時にサービスアカウント認証情報を使用してコントロールプレーンに認証し、設定（ルート、ポリシー、アップストリームターゲット）を受け取ります。設定の更新はリアルタイムでWarpgateにプッシュされます。
アウトバウンド専用モデルのセキュリティ特性
反転イングレスアーキテクチャにより、いくつかの重要なセキュリティ特性が生まれます：
- 公開インバウンドオリジン不要：顧客ワークロードにはオープンなインバウンドポート、パブリックIPアドレス、それを指すDNSレコードが不要です。既存の直接経路を閉じれば、スキャン、探索、フィンガープリントできるものはありません。
- オリジン非露出：従来のCDNやリバースプロキシアーキテクチャとは異なり、エッジが唯一の入口である限り、発見されて直接攻撃されうる「オリジンIP」は存在しません。Warpgateを追加しても既存の公開リスナーやファイアウォールルールは消えません。
- 全経路mTLS：Warpgateとエッジノード間のすべての接続でTLS 1.3と相互認証を使用。双方が証明書を提示し、相手のアイデンティティを検証します。
- 事前認証済みトラフィック：保護されたルートでは、ワークロードはエッジですでに認証・認可されたトラフィックのみを受信します。公開ルートはエンドユーザー認証なしで通過します。アプリケーションは独自のトークン検証を実装するのではなく、信頼されたアイデンティティコンテキストを利用します。
- 多層防御：セキュリティポリシーはエッジ（第１層）で適用され、Warpgate（第２層）でも再度検証された後にトラフィックがワークロードに到達します。
ユーザーディレクトリ（User Directory）
プロジェクトまたは組織にスコープされたエンドユーザーアカウントのコレクションです。ユーザーディレクトリにより、異なるサービスに対して別々のユーザープールを管理できます。
例：SaaSアプリケーションでは、顧客向けユーザー用と内部管理者ユーザー用に別のユーザーディレクトリを持つことができます。
ユーザーアカウント（User Account）
Secure Ingressを通じてサービスにアクセスするエンドユーザーです。ユーザーアカウントには以下があります：
- ステータス：active、inactive、suspended
- ログイン追跡：最終ログインタイムスタンプと認証履歴
- プロフィール情報：名前、メール、表示名
ルートで認証が有効な場合、Secure Ingressは完全なログインフロー（サインアップ、ログイン、パスワードリセット）を管理し、リクエストをWarpgateに転送する前にエッジでアイデンティティを検証します。