1. シナリオ、ゴール、および非ゴール
インフラチームが共有 Gateway を運用し、アプリケーションチームは各自のネームスペースにサービスをデプロイします。決済サービスは Gateway が平文を一切認識しないことを要求し、内部管理サービスはエッジでのクライアント証明書の検証を必要とし、監査人はルートの変更とハンドシェイクの失敗が記録されることを求めています。証明書、バックエンド、およびリスナーの権限を制限したまま、チームはルートを個別に公開できる必要があります。
まず非ゴールを明確にします。Gateway API リソースは意図（intent）を表現します。具体的な TLS 実装、ロードバランシングの動作、および証明書の保存は、GatewayClass コントローラーのプロパティのままです。したがって、設計にはコントローラーの機能マトリックスと互換性チェックが必要です。1 つの実装の動作を API の保証として扱うことはできません。
2. Gateway API 1.5 の機能を分解する
Gateway API 1.5 では、TLSRoute、フロントエンドのクライアント証明書検証、および関連するバックエンド TLS 機能が安定サポートへと移行し、ReferenceGrant が v1 に昇格しました。TLSRoute は TLS ハンドシェイクの SNI からホスト名をマッチングし、接続をバックエンドに転送します。リスナーは Passthrough または Terminate を使用できます。
Passthrough では、Gateway は暗号化されたバイトをプロキシし、バックエンドが証明書とハンドシェイクを所有します。Terminate では、TLS は Gateway で終了し、復号された TCP がバックエンドに送信されます。鍵の所有権、データの可視性、およびポリシーの実行ポイントが異なるため、パフォーマンスだけでどちらかを選択することはできません。
3. リソースと所有権の設計
プラットフォームチームが Gateway とリスナーを作成し、アプリケーションチームは名前付きリスナーにバインドされた TLSRoute オブジェクトを作成します。1 つのルートが Gateway 全体を占有することを許可する代わりに、parentRefs.sectionName を使用してルートを明示的なリスナーにバインドします。ホスト名、ポート、プロトコル、および証明書の参照は、レビュー対象のポリシー入力となります。
このリソースのペアは passthrough の意図を表します。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: tls-passthrough
protocol: TLS
port: 8443
tls:
mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: payments
namespace: payments
spec:
parentRefs:
- name: shared-edge
namespace: infra
sectionName: tls-passthrough
hostnames: ["pay.example.com"]
rules:
- backendRefs:
- name: payments
port: 8443クロスネームスペース参照は、コントローラーの認可メカニズムを通過し、ReferenceGrant または同等のポリシーによって明示的に許可される必要があります。デフォルトの可視性に依存してはいけません。
4. Passthrough と Terminate の選択
Passthrough は、Gateway が秘密鍵を保持せず、アプリケーションプロトコルを参照しないことを意味します。これは、厳格なエンドツーエンドの暗号化、直接的なバックエンド相互 TLS、または暗号化された TCP 要件に適しています。トレードオフとして、Gateway は HTTP コンテンツに基づくルーティング、統一されたアプリケーション層の制限の適用、またはエッジでのクライアント証明書の検証を実行できず、バックエンドがハンドシェイクと証明書のローテーション作業を担います。
Terminate は証明書管理を一元化し、エッジでのクライアント証明書の検証、一貫したルーティング、および一貫した可観測性を可能にします。トレードオフは、Gateway での平文の可視性です。バックエンドへのホップを暗号化したままにする必要がある場合は、バックエンド TLS も構成します。秘密鍵の露出リスクとコントローラーの障害ドメインも拡大します。
面接で評価される設計は階層化されています。極めて機密性の高い決済接続はデフォルトで passthrough にし、一元化された ID とポリシーを必要とする管理サービスは terminate し、その後の 2 番目のホップをバックエンド TLS で保護します。
5. フロントエンド mTLS とトラストアンカー
フロントエンド mTLS は、クライアントと Gateway 間の接続を検証します。Gateway はクライアント証明書を設定された CA バンドルと照合してチェックします。厳格モード（strict mode）は検証済みのクライアントのみを受け入れます。安全でないフォールバックでは、証明書の欠落や無効な証明書がバックエンドに到達することを許可してしまう可能性があるため、ネットワークポリシーや監査アラートと組み合わせた明示的な例外とする必要があります。
トラストアンカーをテナントまたは環境ごとにグループ化します。制御された Secret または ConfigMap 参照を通じて CA バンドルを配布します。アプリケーションチームにプラットフォームの秘密鍵の参照を受け取らせてはなりません。ローテーション中は、新しい CA を公開し、デュアルトラスト期間を監視し、古い CA を失効させ、アクティベーションの時間とスコープを記録します。
6. マルチテナント認可と競合
共有 Gateway 上のリスナーはプラットフォームの境界です。アプリケーションは、承認されたホスト名とバックエンドのみを要求する必要があります。コントローラーは、重複するホスト名、未認可の parentRefs、クロスネームスペースのバックエンド、およびポリシー外のポートやプロトコルを拒否し、リソースの status に理由を公開する必要があります。
アドミッション時に ReferenceGrant、Secret の参照、および GatewayClass の機能を検証します。Git でポリシーの変更をレビューします。ランタイムにおいて、コントローラーは承認されたリソースからのみ構成をレンダリングする必要があります。ルートの競合が発生した場合は、最後の既知の適切な構成を維持し、最後に書き込んだものが勝つ（last-writer-wins）動作で他のテナントを暗黙的に上書きすることを許さず、Accepted=False を報告します。
7. 障害、アップグレード、および可観測性
ロールアウトの前に、コントローラーが安定版の TLSRoute バージョン、選択した TLS モード、クライアント検証、およびバックエンド TLS をサポートしていることを確認します。Gateway API のアップグレードでは、実験的リソースから安定版の v1 への移行が必要になる場合があります。YAML の URL を置き換えるだけでは不十分です。
SNI の一致、リスナーとルートの conditions、証明書の有効期限、クライアント証明書の失敗理由、バックエンドの接続エラー、構成の伝播レイテンシ、およびテナントごとのハンドシェイクとトラフィックのメトリクスを監視します。フェイルオーバー中も、トラストバンドル、ルート状態、およびバックエンドのヘルスチェックの一貫性を維持します。Gateway が利用できない場合は、平文トラフィックでそれをバイパスするのではなく、明示的な DNS またはロードバランサーのフォールバックを定義します。
8. 評価基準とフォローアップ
説明が必須の項目
- TLSRoute の SNI ルーティングを、Passthrough および Terminate の鍵と平文の境界から区別すること。
- フロントエンド mTLS のための CA 信頼、ローテーション、障害ポリシー、およびクロスネームスペース認可を設計すること。
- 単に YAML を貼り付けるだけでなく、コントローラーの機能の違い、リソース conditions、アップグレード移行、および可観測性を説明すること。
フォローアップの質問
- 2 つのネームスペースが同じ SNI を要求した場合、暗黙的な上書きをどのように防ぎますか？
- Gateway が TLS を終了した後、2 番目のホップがコンプライアンスに準拠した暗号化を維持することをどのように保証しますか？
- クライアント CA のローテーション中、古い証明書の最大有効期間を制限しながら、デュアル証明書をどのようにサポートしますか？
採点ガイド
優れた回答は、リソースの所有権、暗号化の境界、認可、およびランタイムのエビデンスを結び付けます。誰が各鍵を保持するかを決定し、status conditions で競合を拒否し、ハンドシェイク、証明書、およびバックエンドのメトリクスによってポリシーを証明します。