セキュアな GKE クラスタを構築するために知っておきたいポイント 2022 年夏(後編)

Kazuki Uchima
google-cloud-jp
Published in
16 min readAug 8, 2022

はじめに

本記事は以下の記事の続きです。まだ前編を読まれていない方がいらっしゃいましたらぜひこちらも読んでみてください。

本記事では以下カテゴリのうち「2. ソフトウェア サプライチェーン セキュリティ」「3. ワークロード セキュリティ」「4. 不適切な設定の検出」を紹介します。

  1. クラスタ セキュリティ
  2. ソフトウェア サプライチェーン セキュリティ
  3. ワークロード セキュリティ
  4. 不適切な設定の検出

ソフトウェア サプライチェーン セキュリティ

GKE 上で動くコンテナ アプリケーションの安全性を担保するためには、ソースコードを書いてからアプリケーションをデプロイするまでの一連の流れ、いわゆるソフトウェア サプライチェーンにおけるセキュリティの検討が重要になってきます。

ソフトウェア サプライチェーンは多くのコンポーネントから成り立っており、様々なリスクが存在します。一例としては、

  • ソースコードや利用している OSS に脆弱性が含まれている
  • 信頼できないリポジトリが提供しているベースイメージ/コンテナイメージにマルウェアや脆弱性が含まれている
  • CI / CD をバイパスした有害なコンテナイメージがデプロイされる

などが考えられます。

https://cloud.google.com/blog/ja/topics/developers-practitioners/secure-supply-chain-google-cloud

一例ですが、以下のように Google Cloud のマネージドサービスを活用しセキュアなソフトウェア サプライチェーンを構築することにより、上記リスクを低減することができます。

https://cloud.google.com/blog/ja/products/identity-security/how-google-cloud-can-help-secure-your-software-supply-chain

まず、リスクとして挙げていた「ソースコードや利用している OSS に脆弱性が含まれている」への対応としては、今後正式なサービスとして利用可能になる Assured Open Source Softfware (Assured OSS)Open Source Insights のデータを活用することで一部リスクを低減することが可能です。

Assured OSS は Google が使用しているものと同じ OSS パッケージを一般公開することで、利用者がある程度の安全性が担保された OSS を利用できるようになるサービスです。これまでは利用者各自で利用する OSS の安全性を確認しないといけなかったところ、Assured OSS を活用することでそのコストを削減することができます。

Assured OSS で公開される OSS は Google によって以下内容が実施された上で公開されます:

  • 脆弱性を発見するため、定期的にスキャン、分析、ファズテストを実施
  • Container / Artifact Analysis データを含む、強化されたメタデータを用意
  • Cloud Build でビルドを行い、SLSA 準拠の検証可能なエビデンスを提供
  • Google によって検証可能な形で署名
  • Google によって保護された Artifact Registry から配布

また、利用している OSS の依存関係の把握やセキュリティリスクの把握に役立つサービスとして Open Source Insights というプロジェクトがあります。

Open Source Insights は npm, Go, Maven (Java), PyPI (Python), Cargo (Rust) エコシステムの OSS パッケージをスキャンし、依存関係をビジュアライズしたり、依存関係に関するセキュリティ アドバイザリやライセンス情報を提供してくれる Web サービスです。

Google Cloud 上では Open Source Insights のデータを BigQuery のデータセットして利用できます。これらのデータを既存のパイプラインやツールと組み合わせることで依存している OSS に関する脆弱性の発見にも役立ちます。

次にコンテナのベースイメージですが、Google では様々なディストリビューションのベースイメージを提供しています。これらのベースイメージは既知の脆弱性がスキャンされ、ソースコードからバイナリまで Google が検証可能なパスを持っています。

信頼できないリポジトリ上のベースイメージを利用すると脆弱性やマルウェア等が混入している可能性もあるため、なるべく信頼できるリポジトリ上のイメージを使ってコンテナイメージをビルドしていただくのをお勧めします。

また、Google は distroless という Shell やパッケージマネージャを含まない軽量イメージも公開しています。アプリケーション実行に必要な最小限のライブラリのみが含まれているため、コンテナイメージ内のアタックサーフェスを小さくすることが可能です。

一方 Shell が含まれていないことによる利便性の観点や利用する言語との相性なども確認した上で、上手くハマりそうであれば利用を検討いただくのが良いかと思います。

Google Cloud では Container Analysis というコンテナイメージの脆弱性をスキャンしてくれるサービスがあります。Artifact Registry や Container Registry といった Google Cloud マネージドのコンテナレジストリ上に Push されたイメージを自動的にスキャンしたり、オンデマンドでコンテナレジストリやローカルにあるイメージをスキャンすることができます。

オンデマンドスキャンの場合、OS パッケージだけでなく GoJava など言語パッケージもスキャン対象となります。

ソフトウェア サプライチェーンでのリスクとして挙げていた「信頼できないリポジトリが提供しているベースイメージ/コンテナイメージにマルウェアや脆弱性が含まれている」や「CI / CD をバイパスした有害なコンテナイメージがデプロイされる」リスクを低減するのに役立つサービスが Binary Authorization です。

Binary Authorization は信頼できるコンテナイメージのみが GKE クラスタにデプロイされることを保証してくれるサービスです。「保証」するというのが具体的に何を指しているかというと、

といった使い方ができます。「認証者による証明書が付与されたイメージのみデプロイを許可する」のケースでは Container Analysis のスキャンでクリティカルな脆弱性が発見されなかったイメージや QA チームのチェックを通過したイメージのみデプロイを許可する、というような制御をすることも可能です。

マルウェアや脆弱性が含まれている可能性のある野良コンテナのデプロイを防いだり、CI/CD パイプラインをバイパスするようなデプロイを防ぐのに有用なサービスです。

ワークロード セキュリティ

続いてワークロード セキュリティに関するお役立ちサービスの紹介です。「ワークロード セキュリティとは?」というところで少し分類を悩んだのですが、ここでは主に実行中のコンテナ アプリケーションの脅威に対する防御という意味で使っています。

ワークロード セキュリティを担保することにより、そもそもの侵入を防ぐことに加えて侵入された後の侵入拡大のリスクを低減できます。

まずご紹介したいのが Anthos Service Mesh (ASM) です。ASM はフルマネージド版の Istio で、Istio のコントロールプレーンを Google 管理の形態で利用できる Managed Control Plane というアーキテクチャも提供しています。Istio が提供する各種セキュリティ機能やトラフィックコントロール機能等を活用することができ、ワークロードの保護に役立ちます。

ASM には多くのセキュリティ関連機能があるのですが、その中でも mTLS 機能を活用すると、アプリケーション側で意識しなくてもサーバ ⇔ クライアント間の相互認証が可能になります。相互認証により、接続先だけでなく接続元の信頼も保証できるというのが特徴です。また、アプリケーション間の通信は TLS により暗号化されます。

これにより、通信の盗聴中間者攻撃 (Man-In-The-Middle) のような攻撃を防ぐのに役立ちます。

少し注意が必要なのは Istio 1.6 以降では自動的に mTLS が有効化されるのですが、デフォルトでは Permissive mode という mTLS で暗号化された通信だけでなく平文も許可するモードが設定されています。

これだと Istio の sidecar が injection されていないメッシュ範囲外のクライアントからの通信も許可してしまい、mTLS による通信元 / 通信先の相互認証や通信の暗号化の恩恵を受けることができない可能性があります。その場合は mTLS を STRICT mode で設定することで、平文通信を許可せずよりセキュアな形で運用が可能になります。

続いてご紹介したいのが Policy Controller です。こちらはマネージド版 Open Policy Agent (OPA) Gatekeeper です。OSS Gatekeeper の各種機能が利用できるのに加え、Google Cloud が提供する事前定義の制約ライブラリを利用することができます。また、インストールのし易さや他 Google Cloud プロダクトとインテグレーションも容易にできるのも良いポイントです。

Policy Controller でクラスタに制約をかけることにより、コンテナアプリケーションや GKE クラスタの設定、 ASM のポリシー等がセキュリティ ベストプラクティスに沿った設定になっていることを強制させることが可能になります。

また、Kubernetes 1.25 以降で Remove される予定の PodSecurityPolicy代替として利用することもできます。

Policy Controller を使うことにより、例えば特定のコンテナリポジトリ上のイメージのみデプロイを許可するということを制御できたり、サイドカープロキシが Injection されることを強制し Istio / ASM のセキュリティポリシーがバイパスされることを防ぐといった使い方もできます。

上記で紹介した制約は Policy Controller の事前定義のポリシーに含まれるため Apply するだけですぐに利用できます。もちろん事前定義にない制約は自身で Rego でロジックを書いて作成・適用が可能です。

また、実行中のコンテナに対する振る舞い検知機能を提供するサービスとして Security Command CenterContainer Threat Detection があります。

Container Threat Detection では元のコンテナ イメージに存在しなかったバイナリ (マルウェアやクリプトマイナー等) の実行リバースシェル実行 (ボットネット) のような異常な挙動・攻撃を検出することができます。

Container Analysis のようなイメージの脆弱性スキャン等だけでは検知・防ぎきれないような攻撃の 検知を実現してくれるサービスです。検出された攻撃は Security Command Center や Cloud Logging に連携しアラートを飛ばすことも可能です。

https://cloud.google.com/security-command-center/docs/concepts-container-threat-detection-overview?hl=ja#detectors

不適切な設定の検出

これまでご紹介してきたような各種セキュリティ設定がされておらず、不適切な設定になっているとそこが穴となってしまう可能性があります。クラスタ数やワークロード数が増えてくると各ワークロードの設定値を把握するのが難しくなります。

そこで便利な機能がワークロード構成スキャンです。最近利用可能になったこの機能はGKE上で動いているワークロードの構成を自動的にスキャンし、各ワークロードが Pod Security Standards に沿ったセキュアな構成になっているかをチェックしてくれます。例えば runAsNonRoot や privileged, allowPrivilegeEscalation のような重要な Security Context 設定が危険な値になっていないか等をチェックしてくれます。(2022年8月現在、追加料金はかかりません)

発見された懸念事項は Cloud Console のダッシュボードや Cloud Logging のログエントリーとして確認が可能です。

また、Network Policy や Binary Authoization、ASM の Authorization Policy / mTLS の設定がどのワークロードで適用されているかを確認するのに便利なのが Anthos セキュリティダッシュボードです。

クラスタで Dataplane V2 のネットワークポリシー ロギングが有効になっている場合、このセキュリティダッシュボード上でワークロードのネットワークポリシー リクエストを確認することもできます。

https://cloud.google.com/anthos/docs/concepts/security-monitoring#view_workload_conectivity

また、Security Command Center の Security Health Analytics を活用すると、GKE クラスタの設定が CIS ベンチマークに準拠しているか等クラスタセキュリティ(前編で紹介したような内容)の観点でチェックしてくれます。具体的には COS が利用されているか、限定公開クラスタが利用されているか、Workload Identity が利用されているか、などをチェックしてくれます。

紹介した3つのダッシュボードはぱっと見だと似たものにみえますが、それぞれ異なる観点で構成がセキュアかどうかをチェックしてくれる便利なサービスです。ぜひ試してみてください。

まとめ

長くなりましたが、ここまで前編・後編とさまざまなコンテナセキュリティ関連機能・サービスを紹介してきました。本記事で各機能・サービスの概要や使い所を理解してもらえたら幸いです。

文章量の都合上、Network Policy など Kubernetes ネイティブな機能や Cloud Armor (WAF, DDoS 対策) のような一般的なセキュリティ対策サービスの紹介は割愛しましたが、本来であればこの辺りの機能・サービスも組み合わせて対策していくのが良いと思います。

Google Cloud には本記事で紹介したもの以外にも多くのセキュリティ機能を提供しています。他のセキュリティサービスについてもぜひ調べてみてください。

では、Google Cloud で安心安全な Kubernetes ライフをお過ごしください!

--

--

Kazuki Uchima
google-cloud-jp

Application Modernization Specialist at Google Cloud. All views and opinions are my own.