問題と範囲
あなたは、各チームがパブリックアドレスをServiceに直接ルーティングするためにService.spec.externalIPsを使用しているベアメタルKubernetesクラスタを管理しています。v1.36へのアップグレード後、非推奨の警告が表示され、セキュリティレビュアーはテナントが任意のアドレスを主張してトラフィックを傍受できるのではないかと懸念しています。移行を設計してください：実際の依存関係を検出し、エントリポイントごとにLoadBalancerコントローラまたはGateway APIを選択し、新規利用をブロックし、ロールバックを実証します。
Kubernetesのドキュメントには、externalIPsはKubernetesによって割り当てられたり所有権が検証されたりしないと記載されています。v1.36ではこのフィールドは非推奨となり、以降のリリースでkube-proxyの動作が無効化され、最終的に削除される予定です。現在の互換性ウィンドウと長期的な目標を区別してください。非推奨化は即時削除ではありません。
背景と境界条件
Serviceネットワーキング、RBAC、アドミッションポリシー、移行順序、および可観測性に焦点を当てます。クラウドロードバランサ、ベアメタルネットワークデバイス、DNSはプラットフォームの依存関係です。それらの規約、アドレス所有権の証明、デュアルエントリウィンドウ、および障害時のフォールバックを明記してください。
面接官がテストするポイント
- Serviceの
externalIPsスペックフィールドと、NodeのExternalIPアドレスや表示されるLoadBalancerアドレスを区別できているか。 - 監査、トラフィック、権限、コントローラ、DNSを通じたエンドツーエンドの移行を追跡できるか。
DenyServiceExternalIPsが既存のビジネストラフィックを削除することなく、新規の書き込みをブロックできるか。- LoadBalancerコントローラ、MetalLBのようなコントローラ、およびGateway APIの所有権とロールバックの境界を比較できるか。
- メトリクスと段階的な切り替えによって、トラフィックのブラックホールやIPハイジャックが発生していないことを証明できるか。
30秒の回答
「Serviceのスペック、監査ログ、DNS、ノードルーティング、実際のトラフィックのインベントリを作成し、各externalIPをテナント、ポート、バックエンドに対応付けます。移行中はDenyServiceExternalIPsを有効にして新規の値のみをブロックし、既存のオブジェクトは削除可能な状態にしておきます。エントリポイントごとに、管理者制御のLoadBalancerコントローラまたはGateway APIを選択し、並行パスを通じてヘルスチェック、送信元アドレス、コネクションドレインを検証した上で、DNSまたはアップストリームを切り替えます。古いトラフィックがゼロになった後、externalIPsを削除し、ロールバック用スナップショットを保持し、監査、5xx、接続障害、アドレス競合のメトリクスによってロールアウトを制御します。」
ステップごとの解決策
- インベントリの作成。
externalIPsを使用しているすべてのService、そのアドレス、ポート、名前空間、オーナー、DNS TTL、プロトコル、EndpointSlices、外部トラフィックポリシー、および最近のトラフィックを一覧化します。このフィールドを、ExternalIPという名前のNode.status.addressesエントリと区別します。
- セキュリティリスクのモデル化。 ユーザーがServiceスペックに
externalIPsを書き込みますが、Kubernetesはそのアドレスを割り当てず、一意性も保証しません。信頼性の低いテナントが他のテナントのアドレスを主張し、トラフィックを傍受する可能性があります。作成、更新、削除、およびkube-proxyルールを監査し、アドレスとテナントごとに異常を関連付けます。
- まず新規利用をブロックする。
DenyServiceExternalIPsを有効にします。これにより、このフィールドを使用する新しいServiceや既存のServiceに追加される新しい値が拒否されますが、既存の値の削除は引き続き可能です。強制適用の前に監査モードまたは低リスククラスタでテストし、既存のオブジェクトは個別に移行します。
- 代替手段の選択。 クラウド環境では、管理者制御の
type: LoadBalancerを優先します。ベアメタルでは、アドレスプールと競合チェックを備えたコントローラを使用します。役割の分離や共有ルーティングが重要な場合はGateway APIを使用します。プラットフォームがGatewayを所有し、アプリケーションが制限されたHTTPRouteオブジェクトを管理します。
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
spec:
gatewayClassName: platform-public
addresses:
- type: IPAddress
value: 192.0.2.4これは管理者所有のアドレッシングのみを示しています。適用する前に、デプロイメントのGatewayClass、コントローラの機能、証明書、およびIPプールを検証してください。
- 並行検証の実行。 新しいエントリポイントを別のホスト名または低いTTLのDNSの背後に配置し、接続成功率、TLS、送信元アドレス、長時間接続、ヘルスチェック、およびEndpointSliceの収束を比較します。IPを再利用する場合は、アップストリームを切り替える前に新しいコントローラに所有権を記録し、2つの実装が同時にそれを広報しないようにします。
- ドレインと削除。 古いエントリポイントで新しい接続がないことを監視し、最大接続ライフタイムを待ちます。監査証跡とロールバック用スナップショットを保持したまま、externalIPsを削除します。順序としては、DNS、ロードバランサ、Service、バックエンドの間で検証可能なパスが少なくとも1つ維持されている必要があります。
- バージョンとロールバックの計画。 v1.36では非推奨警告が出力されます。公開されているタイムラインでは、kube-proxyの動作無効化は早くてもv1.40、完全な削除は早くてもv1.43と見込まれています。ロールバックでは、所有権が検証された古いエントリポイントのみを復元し、任意のテナントによる書き込みを再開することは決してありません。代替手段に障害が発生した場合は、新たなリスクをブロックし続けたまま、一時的にDNSまたはコントローラの設定を元に戻します。
模範解答
すべてのexternalIPを盲目的に置き換えるフィールドとしてではなく、移行アセットとして扱います。APIインベントリ、監査、DNS、ノードルール、トラフィックログによって、アドレス、テナント、ポート、接続ライフタイム、所有権を確定します。このフィールドはユーザーが書き込み可能なServiceスペックであり、Kubernetesは割り当てや競合チェックを行わないため、CVE-2020-8554クラスの傍受リスクが生じます。
移行中はDenyServiceExternalIPsを有効にして、既存の値の削除を維持しながら新規追加を拒否します。代替手段はエントリポイントによって異なります。クラウドLoadBalancer、管理者アドレスプールを備えたベアメタルコントローラ、またはプラットフォーム所有のGatewayとアプリケーション所有の制限されたルートを持つGateway APIです。並行ホスト名または低TTLによる切り替えにより、接続、TLS、送信元アドレス、ヘルスチェックの動作を比較した上で、古い接続をドレインしてフィールドを削除します。
計画には、v1.36の警告、最も早い場合でv1.40に予定されているkube-proxy動作の変更、および最も早い場合でv1.43の完全削除を記録します。ロールバックでは、検証された管理者所有のエントリポイントのみを復元します。アドレス競合、5xx、接続障害、DNS伝播遅延、および残存するServiceを追跡します。
よくある間違い
- 間違い： 非推奨化を即時削除として扱う → 失敗する理由： 互換性ウィンドウを誤認し、予期しないダウンタイムを引き起こす → 修正方法： 警告、動作の無効化、削除を別々のマイルストーンとして計画する。
- 間違い：
externalIPsを直接loadBalancerIPに置き換える → 失敗する理由： アドレスプールや競合チェックが依然としてバイパスされる可能性がある → 修正方法： 管理者制御のコントローラにステータスの割り当てと公開を行わせる。 - 間違い： アドミッションの強制開始時に古いフィールドをすべて削除する → 失敗する理由： トラフィックや接続ドレインの証拠がない → 修正方法： 追加をブロックし、代替手段をカナリアリリースし、ドレインしてからアセットごとに削除する。
- 間違い： DNS、ノードルール、トラフィックを確認せず、Serviceのみを確認する → 失敗する理由： 隠れたエントリポイントやブラックホールが残る → 修正方法： エンドツーエンドの移行インベントリと監視ウィンドウを維持する。
- 間違い： テナントにGatewayアドレスを所有させる → 失敗する理由： 代替手段が同じ権限の欠陥を再作成してしまう → 修正方法： プラットフォーム所有のGatewayと制限されたアプリケーションルートを使用する。
フォローアップの質問と回答
DenyServiceExternalIPsは既存のServiceに影響しますか？
このフィールドを使用する新しいServiceや、既存のServiceに追加される新しい値を拒否します。既存の値の削除は引き続き可能です。ターゲットバージョンで動作を検証し、拒否イベントを監視してください。これは保護機能であり、自動移行ツールではありません。
ベアメタルでLoadBalancer IPを手動入力してはいけない理由は何ですか？
手動割り当てでは、アドレスプール、競合検出、ヘルス状態、監査が依然として不足しています。管理者所有のプールを持つコントローラを使用することで、割り当て、解放、一意性がプラットフォームの責任となります。固定アドレスには依然として明示的な承認が必要です。
Gateway APIはどのようにしてアプリケーションのセルフサービスを維持できますか？
プラットフォームがGatewayとGatewayClassを作成し、アドレス、リスナー、クロスネームスペース参照を制限します。アプリケーションチームは、参照ポリシー、ポリシーオブジェクト、監査制御に従ってHTTPRouteを提出します。
長時間接続やWebSocketはどのように処理しますか？
DNSまたはエントリポイントを切り替える前に接続ライフタイムを測定します。古いパスでの新規接続を停止しつつ、既存の接続はドレインできるようにし、必要に応じてデュアルエントリの再試行動作を利用します。メトリクスでは新規接続の失敗と正常な切断を区別します。
ロールバックの切り替えスイッチはいつ削除できますか？
古いトラフィックがゼロになり、すべてのServiceからフィールドが削除され、アドレス競合チェックに合格し、DNS TTLウィンドウが終了し、新しいパスが監視SLOを満たした後に削除できます。その後、監査証跡を保持したままスナップショットを削除します。カレンダーの日付だけで証拠の代わりにはできません。
参考資料
- Kubernetes v1.36 Service ExternalIPsの非推奨化 (Kubernetes Blog)
- Serviceドキュメント (Kubernetes Documentation)
- Admission Controlドキュメント (Kubernetes Documentation)
- Gateway APIドキュメント (Kubernetes Documentation)
面接チェックリスト
フィールドのセマンティクスをセキュリティリスクから切り離し、次に手順を提示します：インベントリ、追加のブロック、代替エントリポイント、並行検証、ドレイン、削除、およびロールバック。
1文でのまとめ
ExternalIPsの移行とは、ユーザーが書き込み可能なエントリポイントを、管理者所有で監査可能かつ検証可能なアドレス割り当てパスに置き換えることです。
さらなる練習
クラスタでGateway API、MetalLB、およびクラウドLoadBalancerを併用している場合、単一のエントリポイントカタログ、アドレス所有権モデル、およびクロス環境ロールバックプロトコルを設計してください。