Google Kubernetes Engine にセキュリティ パッチを適用する際のお客様の課題を解決する方法

※この投稿は米国時間 2023 年 5 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: このブログ投稿は、2023 年 4 月版 Threat Horizons レポートから編集されたものです。

クラウドのお客様は、提供される可用性、柔軟性、セキュリティの観点から、Kubernetes クラスタでコンピューティング ワークロードを実行することが増えています。他の IT アセットと同様に、これらのクラスタもその機能を最新に保ち、セキュリティやバグの修正をインストールするために定期的にパッチを適用する必要があります。2021 年から 2022 年にかけて収集されたデータを確認したところ、Google Kubernetes Engine（GKE）のお客様でクラスタへのセキュリティ パッチの適用が遅れる場合のあることが判明しました。適用を遅らせる主な原因は、パッチ適用によって本番環境のオペレーションが誤って中断されるのではないかという懸念です。セキュリティ パッチの適用を遅らせることは、短期的には最も効果的な解決策に見えるかもしれませんが、そうすることで組織が直面するリスクを増大させる可能性があります。

GKE のお客様は、以下の方法でワークロードの可用性を維持し、セキュリティ パッチを最新の状態に保つことができます。

1. Kubernetes 環境の構成とオーケストレーションにより、ビジネスの継続性を維持しながらパッチの適用を加速させる

2. ビジネスのニーズに合わせて、適切なメンテナンスの時間枠とメンテナンスの除外枠を指定する

3. 通知サービスやスキャン サービスを利用して脆弱性を発見し、セキュリティ パッチのインストールを計画する

GKE のお客様は、Kubernetes クラスタの可用性とセキュリティ パッチのトレードオフを懸念しています。お客様のワークロードは、ブラック フライデーや大晦日のような重要な本番環境の時間枠に実行する必要があります。セキュリティ パッチを適用すると、パッチ適用中にシステムがダウンしたり、さらにはパッチ適用後にサービスが停止したりする可能性があるため、可用性に影響を与える場合があります。たとえば、パッチによって IT 環境全体に誤って新しいバグが発生してしまう可能性があります。

お客様との対話から、セキュリティと可用性のバランスを取るにあたり、セキュリティ パッチの適用を長引かせたり遅らせたりした主な理由が明らかとなりました（これらの懸念に対する解決策の提案は、この投稿の最下部に記載されています）。

• お客様のアプリケーションで、セッションやその他同様のメカニズムを介して「状態」を維持する必要がある場合、予期せぬパッチ適用によってその状態が損なわれることが懸念されています。これは、固定されたセッションを含むノードホスト型ロードバランサやウェブサーバーをリサイクルする際に発生する可能性があり、そのアプリケーションの実行に影響が及ぶ恐れがあります（この問題はこの投稿の下部で説明されているように、Pod Disruption Budget と Termination Grace Policy で対処できます）。

• バッチや AI / ML アプリケーションを実行する他のお客様の場合も、「状態」を維持する必要があるケースと同様です。パッチ適用中に未完成のワークロードが再起動する可能性があるため、ML の「トレーニング」のような作業がパッチ適用によって中断されることが懸念されていました。しかし、このようなクライアントの場合、パッチを適用すること自体ではなく、中断させないことが目的です。クラスタノード（お客様がワークロードを実行する Kubernetes クラスタを構成する仮想マシンなど）が中断することなく終了できる場合、パッチを適用することなく終了させることができます。これらのワークロードは、実質的には「1 回限り」のジョブです（このようなワークロードのパッチ適用に関する懸念は、この投稿の後半で紹介するメンテナンス除外構成によって軽減できます）。

• アップグレードによって API に予期せぬ変更をもたらし、アプリケーションの機能が損なわれる可能性があることを懸念したために、セキュリティ アップグレードを遅らせたケースもありました。しかし、マイナー バージョン（Kubernetes クラスタ全体の運用環境のバージョン）内でセキュリティ アップグレードが発生する際に API は変化しません。アップデートは、現在のマイナー バージョンのみをアップグレードし、より新しいマイナー バージョンにはアップグレードしないように構成できます（アップデートの範囲を制御できるなど）。しかし、この構成オプションは、必ずしもお客様に認知されているわけではありませんでした。

• 非常に大規模なノードフリートを持つお客様にとっては、パッチ適用に時間がかかり、脆弱なセキュリティ体制の状態が長くなってしまう可能性があります。デフォルトの GKE ノードのパッチ適用メソッドはサージ アップグレードで、デフォルトのノード アップデート パラメータである maxSurge は 1 に設定されています。このパラメータを変更することでパッチ適用を高速化できますが、デフォルトの値では、一度に 1 ノードしか更新できないため、パッチ適用のプロセスが長くなります。その結果、環境が脆弱なノードで実行される期間が長くなります。

しかし、セキュリティ パッチの適用を長引かせたり遅らせたりすることは、それ自体に課題があります。古い GKE パッチリリースで実行されるクラスタは、新しいパッチリリースで実行されるクラスタと比較して、2 倍、3 倍、またはそれ以上のオープン CVE を有していました。実質的に、管理されていないリスクは時間の経過とともに蓄積されます。

Google は、2022 年 10 月までの 1 年間分のノードパッチ適用データを調べました。この期間、お客様は複数の GKE マイナー バージョンとさまざまな Container-Optimized オペレーティング システム（COS、マイナー バージョン内でデプロイされる実際の OS イメージ）を実行していました。この時期の GKE マイナー バージョンの一つである 1.20 とそれ以降のマイナー バージョンの一つである 1.22 における COS の中程度と高程度の CVE の相対数を図 1 と図 2 に示します。

このグラフは、「自動アップグレード」プロセスを使用した場合の時間の経過に合わせたパッチのライフサイクルを示すもので、その間、Google は定期的に同じマイナー バージョン内のお客様のクラスタにパッチを自動的にデプロイします。グラフは、相対的な CVE の割合、つまり、ある自動アップグレード リリースの CVE 数を、同じマイナー バージョンの最初の自動アップグレード リリースの CVE 数と比較したものです。ご覧のように、より最新のリリースのクラスタにパッチが適用され、より最新のリリースで見つかる CVE が少なくなるにつれて、その割合は一般的に 2 倍、3 倍、またはそれ以上の倍率で減少しています。

次の提案は、お客様が可用性とセキュリティ パッチの適用をより統一された方法で実現する方法を説明するものです。

GKE における可用性とセキュリティ パッチ適用のバランスをとるためのソリューション

1. クラスタがリリース チャンネルにあることを確認します。これは、Google が管理するロールアウトのポリシーで、お客様は適切な関連アップグレードのパスを選択できます。また、このチャンネルは、Kubernetes の新機能、セキュリティ、バグの修正を使用してお客様のクラスタを自動的に維持します。Google Cloud は、3 つのリリース チャンネル（Rapid、Regular、Stable）のうち、セキュリティ パッチのスピードと可用性の有用なバランスを提供する Regular チャンネルを推奨しています。どちらにしても、セキュリティに関する修正は 3 つのチャンネルで適時自動的に公開され、パッチが適用されます。

2. 適時行われる適切な期間のメンテナンスの時間枠（環境のアップグレードが許可される時間帯を指定）を使用し、本番環境処理が許可されたときにノードにパッチが適用されるようにします（しかし、大規模なクラスタでは、メンテナンスの時間枠が短いと、1 サイクルでパッチの適用を完全に完了させるには不十分な場合があります）。

3. メンテナンス除外ウィンドウ（MEW、環境のアップグレードが禁止される時間帯を指定）を使用し、中断できない作業期間にパッチの適用が行われないようにします。除外する時間枠だけでなく、範囲も指定できます。たとえば、特定のマイナー バージョンの更新は続けても、より新しいマイナー バージョンへの移行（たとえば、API の機能が変更される可能性がある移行）は、MEW を使用して除外できます。

4. デフォルトのノードプールのパッチ適用方法は、従来と同様にサージ アップグレードです。非常に大規模なクラスタでサージ アップグレードを使用する場合、maxSurge パラメータをデフォルトの 1 より増やすことを検討してください。1 つ以上のノードに同時にパッチが適用されるため、ノードフリートへのパッチ適用を高速化できます。デプロイされるアプリケーションがパッチ適用中の停止にも対応できる場合は、maxUnavailable パラメータをデフォルトの 0 より大きくしてください。これにより、本番環境ノードの一部がダウンする可能性がありますが、これは定義上許容されるべきことで、パッチ適用完了までの時間を短縮します。

5. ステートフルおよび類似のワークロードの場合、Pod Disruption Budget（PDB）を設定します。Pod は、ノード内で実行されるワークロードのサブタスクです。適切な PDB を設定することで、セッション ベースのアプリケーションや同様のアプリケーションで、パッチ適用中も予算で指定された「利用可能な最小数の」Pod を引き続き実行できます。必要な場合は終了猶予期間を長くして、パッチ適用プロセスの間に Pod がシャットダウンされる際、必要に応じてワークロード タスクを正常にシャットダウンするための十分な時間を割り当てられることができます（デフォルトは 30 秒です）。

6. 本番環境ワークロードの可用性をさらに高めるには、お客様は GKE 環境を作成する際にゾーンクラスタではなく、リージョン クラスタを設定する必要があります。ゾーンクラスタのパッチ適用中は Kubernetes API にアクセスできなくなり、Kubernetes に依存している本番環境アプリケーションに影響を与える可能性があります。しかし、リージョン クラスタにはこのような制限はありません。ゾーンクラスタには、Kubernetes クラスタを管理するソフトウェア インフラストラクチャであるコントロール プレーンが 1 つだけあります。
   
   ゾーンクラスタへのパッチ適用中は、API のマネージャー（コントロール プレーン）が使用できないため、Kubernetes API は使用できません。一方、リージョン クラスタは、コントロール プレーンの冗長性が 3 つあり、パッチが適用されると、1 つのコントロール プレーンは利用できなくなりますが、他のコントロール プレーンが利用可能になります。利用可能なコントロール プレーンは、他の機能に加えて、Kubernetes API のオペレーションを維持します。

7. 現在パブリック プレビュー中のセキュリティ対策ダッシュボード（SPD）を使用して、クラスタ内のさまざまなセキュリティ上の懸念を見つけることができます。SPD により、ワークロードの構成ミスやノードで使用されている OS イメージの CVE を探す脆弱性スキャンを開始し、その結果はダッシュボードで提供されます。追加のレポート機能として、脆弱性スキャンの結果も Cloud Logging に提供されます。

8. さまざまな通知サービスを活用することで、クラスタに関するセキュリティ意識をさらに高めることができます。サポートの終了に関する分析情報と推奨事項を確認して、環境内で変更を軽減する方法の提案を含め、将来的にどの API やその他の GKE 機能が変更されるかを判別することもできます。GKE Pub/Sub に登録すると、実行中の特定のクラスタ バージョンに合わせたセキュリティに関する公開情報およびパッチリリース情報を受け取れます。どちらの通知も、プランニングやチェンジ マネジメントの目的に使用できます。