Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。2022年8月23日にKubernetes v1.25がリリースされました。このバージョンでは「Pod Security Policy」が削除され、「Pod Security Admission」がGAになり、Podセキュリティのデファクトスタンダートがバトンタッチされました。今回は、このPod Security Admissionについて詳解します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Kubernetesは今やコンテナ実行基盤のデファクトスタンダードですが、そこにデプロイするコンテナ(Pod)の設定について、どの程度意識できているでしょうか。KubernetesにPodをデプロイする際には、マニフェストでコンテナに対するさまざまな設定ができます。しかし、その設定次第では、デプロイしたPod、ひいてはKubernetesクラスタ全体に致命的な脆弱(ぜいじゃく)性をもたらすことにつながります。
Kubernetesでは、このようなPodに対する脆弱な設定を未然に防ぐ機能として、これまでは「Pod Security Policy」がβ版として提供されていましたが、本機能は正式リリース(GA)で日の目を見ることなくKubernetes v1.25で削除されました。それに代わる機能としてKubernetes v1.25では、「Pod Security Admission」がGAとなり、正式に利用できるようになりました。
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回は、脆弱な設定によるセキュリティリスクを踏まえ、Pod Security Admissionを用いてどのようにセキュリティリスクを回避するかについて解説します。
脆弱なコンテナ設定を含むPodをKubernetesにデプロイすると、以下のようなリスクにつながる場合があります。
脆弱なコンテナの設定を含んだ状態でWebサーバPodをデプロイし、外部に公開しているケースを想定します。
万一、外部の攻撃者が何らかの手段によってWebサーバPodに侵入できた場合、攻撃者はコンテナの脆弱性を悪用してWebサーバPodのみならず、そのPodがデプロイされているホストや、そのホスト上で動作している他のPodなど、攻撃の範囲を特定のPodだけでなく基盤全体に拡大できることになります。
Kubernetesクラスタをコンテナ基盤としてアプリ開発者に提供しているケースを想定します。アプリ開発者にはKubernetesにPodをデプロイするといった基本的な操作は許可したいですが、Worker Nodeなどのクラスタ構成要素にはアクセスさせたくありません。
ところが、悪意のあるアプリ開発者が脆弱なコンテナ設定を含むPodをKubernetesにデプロイした場合、悪意のある開発者は自身のデプロイしたPodを経由して本来権限の与えられていないWorker Nodeに不正にアクセスし、攻撃できてしまうケースがあります。
脆弱なコンテナの設定に伴うリスクの例を2点挙げましたが、説明だけ聞いても具体的にぴんとこない方も多いと思います。そこで具体的なリスクを実感するために、ここでは実験として脆弱なコンテナの設定を含むPodマニフェストを用いてKubernetesにPodをデプロイし、コンテナの設定が脆弱だとどのようなことができてしまうのかを見てみましょう。
この実験は必ず検証環境など他のサービスに影響のない環境で実施してください。
本内容は決してサイバー攻撃を肯定するものではありませんので悪用はしないでください。
脆弱なコンテナの設定を含むPodマニフェストを用意します。
Copyright © ITmedia, Inc. All Rights Reserved.