代表的な面接トピック

バックエンド面接:Gateway APIのBackendTLSPolicyをどのように活用しますか?

バックエンド普通
Offer.cc 編集チーム公開日 更新日

質問

ゲートウェイでクライアントTLSを終端しますが、Serviceへの接続も暗号化する必要があります。証明書検証を無効化する代わりに、どのようにBackendTLSPolicyを評価しますか?

プロンプトとコンテキスト

クラスターのGatewayが外部からのHTTPSを受け入れ、TLSのみを受け入れる内部Serviceにリクエストを転送します。Gateway APIのBackendTLSPolicyを使用してアップストリームTLSを設定し、証明書とホスト名を検証し、無効なポリシー、クロスネームスペース参照、およびロールバックを処理する方法を説明してください。

面接官がテストしていること

  • クライアントTLS終端と、GatewayからバックエンドへのTLS発信を区別できているか。
  • ポリシーがターゲット参照を通じてServiceにアタッチされ、実装を介してステータスを報告することを理解しているか。
  • CA、サーバー名、クライアント証明書、および検証をスキップするリスクについて説明できるか。
  • クロスネームスペースの認可、互換性、可観測性、ロールバック、および段階的移行を考慮できているか。

尋ねるべき確認質問

  1. TLSはGatewayで終端して再開始されますか、それともエンドツーエンドでパススルーされますか?バックエンド証明書のSANにはどのサービス名が含まれていますか?
  2. どのネームスペースがCA、クライアント証明書、秘密鍵を所有しており、ReferenceGrantやその他の認可が必要ですか?
  3. Gateway実装は現在のBackendTLSPolicyバージョンおよび対象のRouteタイプをサポートしていますか?
  4. 証明書ローテーション、無効なポリシー、またはバックエンドTLS障害の発生時、トラフィックはどのように監視、隔離、ロールバックされますか?

30秒での回答

クライアントからGatewayへの終端と、GatewayからServiceへのアップストリームTLSという2つのTLS区間を分離します。BackendTLSPolicyはServiceにアタッチされ、検証用マテリアルに加えてオプションのクライアント識別情報を宣言します。実装側はポリシーが有効かどうかを報告する必要があります。ロールアウト前に、証明書のチェックを決してバイパスすることなく、CA、サーバー名、ポート、クロスネームスペースの認可、および実装のサポート状況を検証します。1つのバックエンドでカナリアリリースを行い、ポリシーステータス、ハンドシェイクエラー、有効期限を監視し、可逆的なロールバックを準備します。

ステップごとの詳細解説

1. TLS境界の定義

Gateway API TLSガイドでは、アップストリームTLS構成をServiceにアタッチされたBackendTLSPolicyに配置します。クライアントTLS終端後、Gatewayはバックエンドに対するTLSクライアントとして機能します。バックエンド証明書は構成された信頼マテリアルに対して検証される必要があり、そのサーバー名は証明書の識別情報と一致していなければなりません。外部リスナーの証明書は、バックエンドの検証構成ではありません。

2. アタッチメントと検証マテリアルの設計

ポリシーのターゲット参照はServiceを指します。検証には、CA証明書の参照または仕様で定義された既知のCAオプションを使用できます。バックエンドで相互TLS(mTLS)が必要な場合は、クライアント証明書と鍵を設定し、Secretへのアクセスを制限します。以下の簡略化された例はフィールドの関係を説明するためのものです。実装に対応するAPIバージョンとサポートされているフィールドを確認してください。

yaml
apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
  name: payments-upstream-tls
spec:
  targetRefs:
    - group: ""
      kind: Service
      name: payments
  validation:
    hostname: payments.internal.example
    wellKnownCACertificates: System

デプロイ前に、ポリシーステータス、参照されているオブジェクト、およびコントローラーの無効理由を調査してください。オブジェクトが作成されたことだけでポリシーがアクティブであるとは証明されません。

3. ネームスペースと証明書ローテーションの処理

ポリシーとターゲットServiceのネームスペース境界を明確に保ちます。クロスネームスペース参照には実装がサポートする認可メカニズムが必要です。GatewayがServiceに到達できるからといって、そのSecretを読み取る権限が付与されるわけではありません。重複期間を設けるかデュアルCA戦略を使用して証明書をローテーションし、ハンドシェイクの成功を確認してから古いマテリアルを廃止し、接続が再確立されることを確認します。

4. 監視、カナリア、ロールバック

まずは1つのServiceまたはポートでカナリアを実行します。ポリシーステータス、TLSハンドシェイクの失敗、バックエンド名の一致エラー、有効期限、および接続の再試行を記録します。ポリシーが無効になった場合、安全な動作とは安全でない接続を拒否して診断可能なイベントを発行することであり、プレーンテキストにサイレントにダウングレードすることではありません。ロールバックでは、最後に検証されたポリシーまたはルートターゲットを復元し、証明書と監査レコードを保持します。

模範回答

まず2つの接続を定義します。外部TLSはGatewayで終端し、その後GatewayはTLSクライアントとしてServiceに接続します。BackendTLSPolicyはそのServiceにアタッチされ、CA、サーバー名、およびオプションのクライアント証明書を宣言します。コントローラーのステータスは、ポリシーが有効であるかどうかの主要なシグナルです。Secretおよびクロスネームスペースへのアクセスを制限し、実装のAPIおよびRouteサポートを確認します。カナリアServiceにより、証明書のSAN、CAの信頼、ローテーション、ハンドシェイクエラー、接続の再確立をテストします。検証の無効化を解決策として扱うことは決してしません。無効なポリシーや証明書の障害は、安全でないトラフィックをブロックし、アラートを発報し、ロールバック計画に従うべきです。

よくある間違い

  • クライアントからGatewayへの証明書のみを設定し、アップストリームTLSの発信を忘れる。
  • targetRef が間違ったオブジェクトを指している、またはすべてのコントローラーが同じAPIバージョンをサポートしていると仮定する。
  • バックエンド証明書のサーバー名を検証せずにCAを信頼する。
  • 検証のスキップやプレーンテキストへのフォールバックによって、CA、SAN、またはローテーションの問題を隠蔽する。
  • 認可や監査の境界を設けずにクロスネームスペースのSecret読み取りを許可する。
  • ステータス、ハンドシェイクメトリクス、コントローラーイベントを無視して、リソース作成の成功を有効性の証明として扱う。

フォローアップ質問と回答

BackendTLSPolicyはクライアントTLS終端とどのように関連していますか?

クライアントTLS終端はブラウザまたは呼び出し元からGatewayまでの区間を保護し、BackendTLSPolicyはGatewayからServiceまでの区間を保護します。これらは異なる証明書および信頼ドメインを使用できるため、識別情報とローテーションは別々に検証する必要があります。

バックエンドの証明書名が一致しない場合はどうしますか?

Gatewayが使用するサーバー名に対してバックエンド証明書を発行するか、ポリシーのホスト名を証明書のSANと一致させます。名前の検証を無効にしてはなりません。DNS、SNI、Serviceの命名、および証明書チェーンを調査してください。

無効なポリシーはどのようにリリース対応しますか?

無効なステータスをアラートおよびリリースゲートに接続し、カナリアの拡大を停止し、参照、CAマテリアル、Secretの権限、および実装サポートを調査します。ステータスが有効になりハンドシェイクが成功した後にのみ続行します。緊急ロールバックでは、最後に検証されたポリシーに戻します。

公開情報ソース

関連する質問