GKE Security Posture でクラスタとワークロードのセキュリティを監査・強化する

GKE 関連のセキュリティ強化に役立つ、GKE Security Posture ダッシュボード(以降、Security Posture)という機能が新たに GA しました。

この記事の執筆時点ではまだ GKE のリリースノートには載っていません。

ただし、Google Cloud ブログの英語版には GKE Security Posture ダッシュボードが GA したことを紹介している記事が出ていました。

cloud.google.com

機能概要

Security Posture では、GKE クラスタクラスタ上に展開されたワークロード構成を自動的にスキャンし、主に以下の観点で結果をダッシュボードに可視化してくれます。

  • 重大度別に分類したセキュリティの懸念事項
  • ワークロードに含まれるコンテナイメージの脆弱性スキャンの結果
  • 運用しているクラスタに関連したセキュリティパッチや Issue の公開情報
  • Security Posture の設定(監査対象となっているクラスタやワークロードの確認)
  • セキュリティを強化するためのナレッジ(動画)へのリンク

Security Posture は Autopilot クラスタと Standard クラスタ のどちらにも対応し、無料で利用することができます1
既存のクラスタに対して有効化することもできますが、無料の機能ということもありバージョン 1.27 以降の GKE クラスタでは今後自動的に有効化されるようです。
また、ダッシュボードとしては GA しているものの、一部の機能(ワークロードの構成スキャン)はプレビュー、というステータスとなっています。

なお、ワークロードを直接監視してコンテナランタイムへの攻撃を検出するといったことはできません。
そうしたソリューションが必要な場合は、Sysdig (Falco) , Prisma Cloud, Google Cloud であれば Security Command Center の Container Threat Detection などが選択肢になるでしょう。
(これらの機能を利用するには別途料金が必要です)

イメージレジストリに対する脆弱性スキャンや、CI パイプライン中でオンデマンドに行う脆弱性スキャンはできません。
ワークロードを展開する前にイメージスキャンを行いたい場合は、Google Cloud であれば Container Analysis がその機能を提供しています。
(こちらも別途料金が必要です)

実機の様子

実際に手元の環境で Security Posture を有効化し、クラスタとワークロードの監査を行ってみました。
Security Posture の利用を開始する(Container Security API を有効化し、スキャン対象のクラスタを選択する)手順は 公式ドキュメント を参照ください。

サンプルのクラスタに適当な Nginx のワークロードを展開したところ、Security Posture のダッシュボードは以下のような表示になりました。
今回はひとつのクラスタのみを Security Posture の監査対象に設定しましたが、複数のクラスタを選択すれば、監査対象となっている全てのクラスタのスキャン結果がまとめてダッシュボードに表示されます。

「懸念事項」のタブをクリックして表示を切り替えると、セキュリティの懸念事項を重大度、分類、ロケーション、クラスタで絞り込めるようになっていました。

Kubernetes Namespace やワークロードでも絞り込めるようになっているのが良いですね。

ここからは、検出されたセキュリティの懸念事項のカテゴリ別(脆弱性、セキュリティに関する公開情報、構成)に、どのような情報が参照できるのかをみていきましょう。

まずは脆弱性のカテゴリから、bind9/1:9.18.12-1 の CVE-2023-2911(debian) という項目を選択しました。

実行中のワークロード(Nginx)に含まれる CVE-2023-2911 の脆弱性についての説明と、推奨される対応、修正されたバージョンなどが確認できます。

次に、セキュリティに関する公開情報のカテゴリから、GCP-2023-008 の項目を選択しました。

こちらは GKE の Security Bulletins に掲載されているセキュリティ Issue の番号と一致したものとなっており、GKE に関連する CVE や、GKE としての対応状況(どのバージョンにアップグレードすれば該当のセキュリティ Issue が解消されるか)などを確認できるようになっています。

このカテゴリに関しては、個々のワークロードというよりも GKE のコントロールプレーンやノードプールに属するノードが影響先となります。
そのため、「影響を受けるリソース」のタブをクリックして表示を切り替えると、Issue の影響を受ける可能性のあるクラスタやノードプールが表示されるようになっていました。

最後に、構成のカテゴリから、root として実行可能な Pod コンテナ の項目を見てみましょう。

こちらはワークロードの定義情報をスキャンし、よりセキュアなマニフェストを書くための推奨事項などが提示されるようになっています。
今回は意図的に Pod の SecurityContext に runAsNonRoot: true を設定せずにデプロイしたため、スキャン結果として root ユーザでの実行が可能である(ゆえにコンテナブレイクアウトのリスクが高くなる)ことが検出されています。

所感

こうしたセキュリティの監査機能は、GKE クラスタやノードの OS といったインフラストラクチャに対する懸念事項と、コンテナイメージの脆弱性スキャンの結果、マニフェストの改善点など、それぞれの観点で別々のダッシュボードや機能が提供されていることが比較的多かったかなと思います。
今回登場した Security Posture では、GKE とそこで稼働するワークロードのセキュリティの懸念事項をまとめて確認でき、必要に応じて情報を絞り込んでいける点が視覚的にわかりやすく作られている印象を受けました。

従来、COS の脆弱性などの、GKE クラスタに関するセキュリティ Issue やパッチの配信状況は Security Bulletins をチェックして各自のクラスタにとっての該当有無を判断する必要がありました。
一方、Security Posture では、利用しているクラスタの構成に応じて該当するセキュリティ Issue だけを表示してくれるため、この機能が登場したことでそうしたパッチの配信状況を確認しやすくなりますね。

また、稼働中のワークロードのコンテナイメージに含まれる脆弱性のスキャンもプラスアルファのセキュリティ対策として有効に使えそうです。
イメージの脆弱性スキャンは、レジストリやオンデマンド実行を対象に導入を始めるケースが多いかとは思いますが、ビルドした後に発見された脆弱性や、レジストリに未登録のコンテナイメージが利用されてしまった場合など、それだけではカバーしきれないセキュリティリスクというものも考えられます。
実行中のワークロードに対しても定期的にスキャンが行われることで、より脆弱性の影響を評価しやすくなるのではないでしょうか。

まとめ

GKE Security Posture ダッシュボードが GA になりました。
クラスタとワークロードの構成をスキャンすることで、セキュリティ上の懸念事項を一元的に確認できる機能となっています。
最新以降のバージョンではデフォルトで有効化されることから、今後の GKE クラスタのセキュリティ管理におけるスタンダードとして活躍が期待できそうです。