こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者さんや、「最近Kubernetesを触り始めたけれど、セキュリティのことがいまいちピンとこないな…」という開発者の方に向けて、今日から現場で役立つ実践的な知識を楽しくお伝えしていきますね。
今回は、Kubernetesのセキュリティにおいて絶対に避けて通れない「Pod Security Admission（PSA）」という仕組みを取り上げます。
「なんだか名前が難しそう…」と思いましたか？大丈夫です！身近な「お家の防犯」に例えながら、一歩ずつ優しく紐解いていきましょう。
—
1. なぜKubernetesにセキュリティ対策が必要なの？（お家の鍵の例え）
皆さんが住んでいるお家を想像してみてください。玄関の鍵をかけ忘れたり、誰でも簡単に開けられる窓のままにしておいたりしたら、泥棒に入られてしまいますよね。
Kubernetesの世界もこれとまったく同じです。Kubernetesは、コンテナという「小さなお部屋」をたくさん管理するマンションのような場所です。もし、そのお部屋の一つが悪い人に乗っ取られてしまったらどうなるでしょうか？
お部屋の鍵が甘い（特権を持ったままになっている）と、悪い人はそのお部屋を踏み台にして、マンション全体の管理室（ホストOS）まで乗っ取ってしまいます。
そうならないために、「このお部屋にはこういう鍵をかけなきゃダメですよ」とルールをピシッと決めて守らせる仕組み、それが Pod Security Admission (PSA) なんです。
—
2. PSAの3つのセキュリティレベルを理解しよう
KubernetesのPSAには、お家の防犯レベルに合わせた3つの「標準的なルール（プロファイル）」が用意されています。
1. Privileged（プリビレッジド：何でもありの特権レベル）
- 例えるなら、「合鍵を家中の人に配り歩いている状態」です。何でもできて便利ですが、セキュリティ的には一番危険です。特別な理由がない限り、通常のアプリでは使ってはいけません。
2. Baseline（ベースライン：最低限の安全レベル）
- 例えるなら、「普通の頑丈な玄関の鍵をかけている状態」です。よくある危険な設定（お部屋の中からマンション全体をいじるような設定）を禁止してくれます。
3. Restricted（レストリクテッド：厳重注意の最高レベル）
- 例えるなら、「二重ロックをかけ、さらに不審者が入ったら警報が鳴るセキュリティシステム」です。アプリ自体も「私は怪しい者ではありません」と証明できる安全な設定で動く必要があります。
現場の基本方針としては、普段は Baseline や Restricted を使い、どうしても必要なところだけ例外を認める という形をとります。これが安全なマンション（クラスタ）を保つ秘訣です。
—
3. 名前空間（Namespace）ごとにセキュリティを適用してみよう
Kubernetesでは、プロジェクトやチームごとに「名前空間（Namespace）」というお部屋の区切りを作ります。PSAのすごいところは、「この名前空間は厳重に（Restricted）、あっちの開発用名前空間は少し緩めに（Baseline）」と、場所ごとにルールを切り替えられる点です。
それでは、実際にYAMLファイルを使って、名前空間にPSAを設定する方法を見てみましょう！
名前空間の設定ファイル（例: namespace.yaml）
以下の設定では、secure-app という名前空間を作り、そこで動くPod（コンテナ）に対して Restricted（最高レベル）のルールを強制しつつ、もしルールに違反するPodが来たら「警告（warn）」を出しつつ「実行を拒否（enforce）」するように指定しています。
apiVersion: v1
kind: Namespace
metadata:
name: secure-app
labels:
# PSAのモードを「enforce（強制）」に設定し、最高レベルの「restricted」を適用します
pod-security.kubernetes.io/enforce: "restricted"
# ルール違反のバージョンを指定します（latestは最新のルールに従うという意味です）
pod-security.kubernetes.io/enforce-version: "latest"
# 違反があった場合に、画面に「警告」を出す設定です
pod-security.kubernetes.io/warn: "restricted"
pod-security.kubernetes.io/warn-version: "latest"このように、ラベル（labels）を一行追加するだけで、Kubernetesが自動的に門番として見張ってくれるようになります。すごく便利ですよね！
—
4. 実際に引っかかりやすいポイントと対策
いざPSAを有効にすると、今まで動いていたアプリが突然動かなくなることがあります。「あれ？エラーが出ちゃった！」と焦る新人さんも多いのですが、大抵は以下の理由で引っかかっています。
よくある落とし穴：root権限で動かそうとしている
古いアプリや適当に作られたコンテナイメージは、コンテナの中の「管理者（rootユーザー）」として動こうとします。しかし、Restricted レベルのルールでは、「root以外の一般ユーザーとして動きなさい！」と怒られてしまいます。
【対策】
アプリのコンテナをビルドする際、またはPodのマニフェスト（deployment.yaml など）の securityContext で、きちんと一般ユーザーとして動くように指定してあげましょう。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-app
namespace: secure-app
spec:
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web-container
image: nginx:latest
securityContext:
# 【重要】root権限での実行を禁止し、セキュリティを担保します
runAsNonRoot: true
runAsUser: 10001 # 一般ユーザーのIDを指定
allowPrivilegeEscalation: false # 特権昇格を禁止しますこのように、コードや設定に少しだけ「お行儀の良い設定」を書き加えることで、厳重なPSAのチェックをすんなりとクリアできるようになります。
—
まとめ
今回は、KubernetesのPod Security Admission (PSA) について、お家の防犯に例えながら解説しました。
- PSAは、コンテナが勝手に危険な権限（特権昇格）を持たないように見張る門番である。
Privileged、Baseline、Restrictedの3つのレベルを使い分ける。- 名前空間のラベルを設定するだけで、簡単にセキュリティの網を張ることができる。
最初は難しく感じるかもしれませんが、インフラの土台を固める大切な一歩です。「一歩ずつ安全なお家を作っていくんだな」という気持ちで、ぜひ自分の環境でも試してみてくださいね。
それでは、また次回のセキュリティ解説でお会いしましょう！
コメント