【入門編】 KubernetesにおけるPod Security Admissionの適用 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

Kubernetesの「鍵」をしっかり閉めて、泥棒（攻撃者）をシャットアウト！〜Pod Security Admissionでクラスターを守る〜

皆さん、こんにちは！サイバーセキュリティの最前線で日々奮闘しているホワイトハッカーです。今回は、最近よく耳にする「Kubernetes（クーバネティス）」という、コンテナを賢く管理してくれる仕組みについて、特に「Pod Security Admission」という機能に焦点を当てて、初心者の方にも分かりやすく解説していきたいと思います。

「Kubernetes？」「Pod？」「Admission？？」と、いきなり専門用語のラッシュで「うっ…」となった方もいるかもしれませんね。でも、大丈夫です！難しい話は一旦置いて、まずは皆さんの身近な「お家」と「泥棒」に例えて、このセキュリティの仕組みがなぜ重要なのか、そしてどうやって守るのかを、一歩ずつ紐解いていきましょう。

泥棒はどこから入ってくる？〜身近な防犯から考えるセキュリティ〜

皆さんのお家には、鍵がかかっていますよね？玄関のドアだけでなく、窓にも補助錠をつけたり、防犯カメラを設置したり、色々な工夫をしていると思います。これは、万が一、泥棒が侵入しようとしても、簡単には入れないようにするためですよね。

実は、Kubernetesのクラスター（たくさんのコンピューターをまとめて賢く動かす仕組み）も、これと似たような考え方で守る必要があります。クラスターの中では、たくさんの「Pod（ポッド）」と呼ばれる小さな箱が動いています。このPodは、アプリケーションを動かすための最小単位で、例えるなら「お部屋」のようなものです。

もし、このPodが、本来持っているべきではない「特別な力」を持っていたり、家の「壁（ホストOS）」に直接穴を開けてしまったり（ホストパスのマウント）すると、そこから泥棒（攻撃者）が忍び込んで、クラスター全体を乗っ取られてしまう危険性があるんです。

Kubernetesの「鍵」を閉める方法 〜Pod Security Admissionの登場〜

そこで登場するのが、今回ご紹介する「Pod Security Admission」という仕組みです。これは、Kubernetesが新しいPodを作ろうとする時に、「このPodは安全な作りになっていますか？」とチェックしてくれる、いわば「玄関の鍵」のような役割を果たします。

具体的には、Podが以下のような「危ない」設定になっていないかを確認してくれます。

  • 「管理者権限」を乱用していませんか？（特権実行）: お部屋に住む人が、勝手に家の壁を壊したり、隣の部屋に勝手に入ったりできるのは困りますよね？Podも同様に、必要最低限の権限だけを持つべきなんです。
  • 「壁」に直接穴を開けていませんか？（ホストパスのマウント）: Podが、クラスターが動いているコンピューター（ホスト）のファイルシステムに直接アクセスできるような設定になっていると、そこから悪意のあるコードを仕掛けられたり、機密情報を盗まれたりする可能性があります。

Pod Security Admissionは、これらの「危ない」設定を「標準で禁止」したり、「推奨される設定」を適用したりすることで、クラスター全体のセキュリティレベルをグッと引き上げてくれるんです。

具体的な「鍵」の閉め方 〜ポリシーを適用してみよう〜

では、実際にPod Security Admissionをどうやって設定するのか、見ていきましょう。Kubernetesでは、「Pod Security Standards (PSS)」という、安全なPodの作り方のガイドラインが定義されています。このガイドラインに基づいて、3つのレベルのポリシーを設定できます。

  • privileged: 最も緩い設定。セキュリティチェックはほとんど行われません。新しくクラスターを始める時や、特定のテスト環境以外では、あまり使わない方が良いでしょう。
  • baseline: 「最低限これだけは守ってね」という設定。特権コンテナの実行や、ホストのファイルシステムへのアクセスなど、比較的リスクの高い設定を禁止します。多くのアプリケーションで利用できる、バランスの取れた設定です。
  • restricted: 最も厳しい設定。「できるだけ安全に」という考え方に基づき、特権コンテナの実行はもちろん、Linuxのケーパビリティ（機能）の制限や、SELinuxなどのセキュリティ機能の利用を強制します。セキュリティが非常に重要なアプリケーションに最適です。

これらのポリシーは、Kubernetesクラスター全体に適用することも、特定のNamespace（クラスター内の仮想的な空間）ごとに適用することもできます。

クラスター全体にポリシーを適用する例

KubernetesのAPIサーバーの設定ファイル（kube-apiserver）で、Pod Security Admissionの機能を有効にし、デフォルトのポリシーを設定します。

# kube-apiserver の設定例 (一部抜粋)
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      mode: enforce # enforce: ポリシー違反は拒否, audit: ポリシー違反は記録, warn: ポリシー違反は警告
      # policies: # 特定のNamespaceに適用したい場合はこちらを設定
      #   defaultNamespacePolicy: restrict
      #   namespaceDefaults:
      #     restricted:
      #       namespaces: ["default", "kube-system"]
      #     baseline:
      #       namespaces: ["development"]

【解説】

  • mode: enforce: この設定にすると、ポリシーに違反するPodは作成できなくなります。まるで「鍵が閉まっているから入れない！」という状態です。
  • auditやwarnといったモードもあり、こちらは「鍵がかかっているけど、無理やり入ろうとした人がいましたよ」と記録したり、警告を出したりする設定です。まずはwarnから始めて、徐々にenforceに移行していくのも良い方法ですね。

Namespaceごとにポリシーを適用する例

Namespaceごとに異なるポリシーを適用することで、開発環境ではbaseline、本番環境ではrestrictedといった使い分けができます。これは、お家の中でも、普段使いの部屋は少し鍵を緩めに、大切な書斎は厳重に、といったイメージですね。

PodSecurityAdmissionは、KubernetesのAdmissionControllerの一つとして機能します。APIサーバーの設定で有効化し、どのNamespaceにどのポリシーを適用するかを定義します。

以下は、Namespaceリソースにpod-security.kubernetes.io/enforceアノテーションを設定して、ポリシーを適用する例です。

apiVersion: v1
kind: Namespace
metadata:
  name: my-secure-namespace
  # Namespaceに直接ポリシーを適用するアノテーション
  # enforce: ポリシー違反を拒否する (必須)
  # audit: ポリシー違反を記録する
  # warn: ポリシー違反時に警告を出す
  annotations:
    pod-security.kubernetes.io/enforce: "restricted" # このNamespaceではrestrictedポリシーを適用
    pod-security.kubernetes.io/enforce-version: "latest" # 適用するポリシーのバージョン
    pod-security.kubernetes.io/audit: "baseline" # auditモードではbaselineポリシーを適用
    pod-security.kubernetes.io/audit-version: "latest"
    pod-security.kubernetes.io/warn: "privileged" # warnモードではprivilegedポリシーを適用
    pod-security.kubernetes.io/warn-version: "latest"

【解説】

  • pod-security.kubernetes.io/enforce: "restricted": このNamespaceで作成されるPodは、restrictedポリシーに準拠していないと作成できません。これが一番強力な「鍵」ですね。
  • pod-security.kubernetes.io/audit: "baseline": ポリシー違反があった場合、それを記録しておきます。後から「誰かが危ない設定をしようとしたな」と確認できます。
  • pod-security.kubernetes.io/warn: "privileged": ポリシー違反の可能性がある場合、警告メッセージを表示します。

これらのアノテーションを設定することで、Namespaceごとにきめ細やかなセキュリティ設定が可能になります。

まとめ 〜セキュリティは「油断」が命取り〜

ここまで、KubernetesのPod Security Admissionについて、お家の鍵に例えながら解説してきました。

  • Kubernetesクラスターも、お家と同じように、泥棒（攻撃者）の侵入を防ぐための「鍵」が必要です。
  • Pod Security Admissionは、Podが「危ない」設定になっていないかをチェックしてくれる、Kubernetesの「玄関の鍵」のようなものです。
  • privileged、baseline、restrictedといったポリシーを使い分けることで、クラスターのセキュリティレベルを調整できます。

サイバー攻撃は日々巧妙化しており、ちょっとした「油断」が大きな被害につながる可能性があります。今回ご紹介したPod Security Admissionは、Kubernetesクラスターを安全に保つための、非常に強力で基本的な対策の一つです。

「難しそう…」と感じた方も、まずはこのブログで触れた基本的な考え方から、少しずつ試してみてください。設定一つでクラスターの安全性が格段に向上します。皆さんの手で、安全で堅牢なKubernetesクラスターを築き上げていきましょう！

もし、さらに詳しい情報や、具体的なトラブルシューティングについて知りたいことがあれば、いつでもお声がけくださいね。一緒にセキュリティの知識を深めていきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました