こんにちは。セキュリティの最前線で、日々「どうすればシステムを泥棒から守れるか」を考えているエンジニアです。
今日は、Kubernetes（K8s）という強力なシステムを運用する上で避けては通れない、「Pod Security Admission（PSA）」についてお話しします。
「コンテナ？ アドミッション？ 何だか難しそう…」と思うかもしれませんね。でも大丈夫。まずは身近な「家の防犯」に例えて、一緒に紐解いていきましょう。
—
1. 家の鍵を「誰にでも開けられる状態」にしていませんか？
Kubernetesの世界では、アプリケーションを動かす最小単位を「Pod（ポッド）」と呼びます。これは、あなたの大切なプログラムが住んでいる「小さな家」のようなものです。
もし、この家の鍵が壊れていたり、誰でも勝手に「合鍵」を作れたりしたらどうでしょう？ 泥棒（攻撃者）は簡単に侵入し、家の家電を勝手に使ったり、家財道具を盗み出したりしますよね。
Kubernetesにおける「Pod Security Standards（PSS）」とは、この「家の守り方」に関するガイドラインのこと。そして「Pod Security Admission（PSA）」は、そのルールを自動的にチェックして、ルール違反の家が建たないように見張ってくれる「管理員さん」のような存在です。
攻撃者は「特権」というマスターキーを狙う
悪意ある攻撃者は、コンテナの中に侵入した後、必ず「特権（Privileged）」というマスターキーを探します。これを持っていると、コンテナの中だけでなく、その親であるホストマシン（家がある土地そのもの）まで操作できるようになってしまうからです。
だからこそ、私たちは「そもそもマスターキーを持たせない（特権コンテナを禁止する）」「root権限で生活させない」というルールを強制する必要があるのです。
—
2. 管理員さん（PSA）を雇ってみよう
Kubernetesには、3つのレベルの「防犯基準」が用意されています。
1. Privileged（許可）: 制限なし。基本的には使いません。
2. Baseline（基本）: 「一般的な防犯」。ルート権限の禁止など、必要最低限の安全を確保します。
3. Restricted（制限）: 「鉄壁の防犯」。非常に厳しい制限をかけ、安全性を最大化します。
新人のうちは、まずは「Baseline」から適用し、徐々に「Restricted」を目指すのが王道です。
設定のやり方：名前空間（ネームスペース）に指示を出す
管理員さんに「このエリアは厳重に管理してね！」と伝えるには、名前空間にラベルを貼るだけです。例えば、`my-app`というエリアを守る場合の設定はこうなります。
apiVersion: v1
kind: Namespace
metadata:
name: my-app
labels:
# Baseline（基本の防犯）を強制する設定
pod-security.kubernetes.io/enforce: baseline
# 違反があったら警告を出す（audit）
pod-security.kubernetes.io/audit: restricted
こう設定しておけば、もし誰かが「特権コンテナ」をデプロイしようとしても、Kubernetesは「ダメです！ルール違反です！」と門前払いしてくれるようになります。
—
3. 開発者が守るべき「3つの鉄則」
現場で実際にコードを書く皆さんに、これだけは守ってほしい「3つの防犯ルール」を伝授します。これらは、`securityContext`という設定項目で指定できます。
spec:
containers:
- name: my-app
securityContext:
# 1. root権限で動かさない
runAsNonRoot: true
# 2. 読み取り専用ファイルシステムにする（攻撃者がファイルを書き換えるのを防ぐ）
readOnlyRootFilesystem: true
# 3. 特権モードを無効化する
privileged: false
- runAsNonRoot: 「自分は管理者じゃないですよ」という証明です。泥棒が入っても、管理者権限がないので被害を最小限に抑えられます。
- readOnlyRootFilesystem: 「家の内装を勝手に模様替えさせない」。攻撃者が勝手に不正なツールをインストールするのを防ぎます。
- privileged: false: これが一番大切です。「マスターキーは渡さない」。
—
最後に：完璧を目指さなくていい、まずは一歩から
セキュリティは「完成したら終わり」ではありません。最初から「鉄壁の守り」を目指すと、アプリケーションが動かなくなって開発が止まってしまいます。
まずは、自分の担当しているPodが`Baseline`設定下でエラーを出さないか確認すること。そして、少しずつ`Restricted`へと引き締めていくこと。この「泥臭い積み重ね」こそが、世界最高峰のセキュリティを作る唯一の道です。
皆さんが書くコードが、今日も安全に、そして元気に動き続けることを応援しています。何か分からないことがあったら、またいつでも聞きに来てくださいね！
コメント