6面の脅威検知とコンテナ不変性【CKS第17回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第17回です。第15回で Falco（syscall）を、第16回で監査ログ（Kubernetes API への操作）を扱いました。本回は D6 Monitoring, Logging and Runtime Security（配点 20%）の締めくくりとして、検知の全体像を 1 枚の地図に組み上げ、ラボに実際に開いている穴を点検します。

本回の中心にある事実を、最初に置きます——防御は、検知を生みません。 readOnlyRootFilesystem で書き込みが弾かれても、既定の Falco はそれを 1 件も記録しません。 「書けなかった」という事実は、コンテナの中で完結して消えます。検知させるには、条件を自分で書く必要があります。

そして本回は、もう 1 つの「できているつもり」も扱います。検知は動き、送信は HTTP 200 で成功し、それでも人には届かない——本ラボの Alertmanager が、そのまま実例になります。「送れた」は「届いた」ではありません。

目次

1. 第17回のスコープ・今ここマップ
   1. 本回の軸: 静かなのは、起きていないからか、見ていないからか
   2. 既習範囲 / 本回で上書きする観点
2. この回のゴール
   1. 本回の起点
   2. 本回で行き来するホスト
3. 点の検知から面の網羅へ —— なぜ CKS は 6 つの面を挙げるのか
4. 6 面 × 観測手段の実機棚卸し
5. 検知の穴を点検する —— 「入れた＝効いている」ではない
   1. 穴①: Users 面が空
   2. 穴②: Gatekeeper は動いているが、何も強制していない
   3. 穴③: Data 面は「保存時」だけ守られている
   4. 点検の作法（読者が持ち帰るもの）
6. 実行時不変性を、検知の観点で読み直す
   1. ルートを全部塞いで、必要な穴だけ 2 つ開ける
   2. PSS Restricted は readOnlyRootFilesystem を要求しない
7. 防御は検知を生まない —— 既定 25 ルールに write 系が 1 本もない
   1. open_write マクロが阻止された書き込みを拾えない理由
   2. 阻止された書き込みを拾う 3 通りの条件
8. やってみよう①：既定では無音であることを確かめ、カスタムルールで可視化する
   1. ステップ1：既存の防御を読む
   2. ステップ2：Falco のログを流しながら、書き込みを試す
   3. ステップ3：open_write 版のルールを書いて、それでも拾えないことを確かめる
   4. ステップ4：evt.res = EROFS 版に書き換えて、可視化する
   5. ステップ5：対照実験（書ける場所で取る）
   6. ステップ5.5：対照 Pod を「不変」にする —— 不変性を自分の手で実装する
   7. ステップ6：後始末
9. やってみよう②：rule_matching: first —— 広いルールが具体的なルールを潰す
   1. 第15回で扱った分と、本回で新しく踏み込む分
   2. ステップ1：広いルールを、具体的なルールの前に置く
   3. ステップ2：広いほうだけが発火する
   4. ステップ3：2 本の順序だけを入れ替える
   5. ステップ4：rule_matching: all という選択肢
   6. ステップ5：first に戻す
   7. この論点が効く場面
10. アラート設計 —— 届かない検知に意味はない
    1. ノイズは priority では落とせない
    2. 検知は二系統ある
    3. 通知先の分け方
    4. 本ラボでの経路の選択
11. やってみよう③：falcosidekick を入れる —— Loki には届き、Alertmanager には届かない
    1. ステップ1：導入 —— helm repo add は要らない
    2. ステップ2：Loki へは既定のまま通る
    3. ステップ3：Alertmanager は chart 既定だと全件 410 で落ちる
    4. ステップ4：200 が返っても、誰にも届いていない
    5. ステップ5：何を直せば届くのか
    6. ステップ6：本回の後始末（回全体）
12. 暗記必須コマンド（コンテナ不変性 / Falco 検知）
    1. 試験ではどう出るか
13. まとめ
14. 理解度チェック（○×形式・全 9 問）
15. 次回予告

第17回のスコープ・今ここマップ#

D6 は 5 つのコンピテンシーで構成されます。本回はそのうち残る 2 つを担当します——6 面にわたる脅威検知と、コンテナの実行時不変性です。

本回の軸: 静かなのは、起きていないからか、見ていないからか#

本回は 3 つの「入れたつもり・届いたつもり」に出会います。 どれも、コマンドを打った瞬間には成功して見えるものです。

既習範囲 / 本回で上書きする観点#

コンテナの実行時不変性は、すでにラボに入っています。 readOnlyRootFilesystem / capabilities.drop: [ALL] / allowPrivilegeEscalation: false / runAsNonRoot / runAsUser: 10001 は fanclub-backend に実装済みで、Pod レベルの seccompProfile: RuntimeDefault は第6回で追加しました。本回はこれを入れ直すのではなく、「検知の観点で読み直す」ところから始めます。 読者が不変性を自分の手で書くのは、やってみよう① ステップ 5.5 の対照 Pod 1 つだけです（本番相当のワークロードを演習で書き換えないためです）。

第3巻 19 回のうち、現在位置は次のとおりです。

第1部 第3巻オリエンテーション
    第1回: 第3巻スコープ + CKA 境界 + 4C/脅威モデル + Kubestronaut

第2部 クラスタ堅牢化（D1/D2）
    第2回: kube-bench + CIS ベンチマーク修復 + バイナリ検証（D1）
    第3回: NetworkPolicy 完全設計 + ノードメタデータ保護 + TLS Ingress（D1）
    第4回: RBAC 監査 + ServiceAccount トークン管理（D2）
    第5回: API Server 堅牢化 + kubeadm アップグレード（D2）

第3部 OS / ノード堅牢化（D3）
    第6回: カーネル層の強制アクセス制御（SELinux/seccomp/capabilities/AppArmor）（D3）
    第7回: ホスト OS の攻撃面最小化と権限管理（D3）

第4部 ワークロード防御（D4）
    第8回: Pod Security Standards + Admission（D4）
    第9回: Secret 管理（etcd 暗号化 / SealedSecrets / ExternalSecrets）（D4）
    第10回: マルチテナンシー分離 + サンドボックス（gVisor/RuntimeClass）（D4）
    第11回: Cilium 透過暗号化 + L7 NetworkPolicy（Calico → Cilium 移行）（D4）

第5部 サプライチェーンセキュリティ（D5）
    第12回: 最小イメージ + 静的解析（Kubesec + KubeLinter）（D5）
    第13回: Trivy イメージスキャン + CI/CD パイプラインセキュリティ統合（D5）
    第14回: SBOM（bom）+ Cosign イメージ署名 + 許可レジストリ制限（D5）

第6部 監視・ログ・ランタイムセキュリティ（D6）
    第15回: Falco ランタイム検知（D6）
    第16回: 監査ログ設計・分析 + 攻撃フェーズ特定（D6）
  ★ 第17回: 多面的脅威検知の体系 + コンテナ不変性 + アラート連携（D6）  ← 今ここ

第7部 インシデント対応・総括
    第18回: セキュリティインシデント対応 DAIR 実戦
    第19回: CKS 試験直前対策 + 第3巻完走宣言 + Kubestronaut への道

この回のゴール#

本回を終えると、次のことができるようになります。到達できたかは記事末の「やってみよう」と「理解度チェック」で確認します。

• 6 つの面それぞれについて「何を・どの手段で見るか」を説明できる
• 自分のクラスタで検知できていない面（穴）を、コマンドで点検できる
• 「入れた＝効いている」ではないことを、Gatekeeper の実例で説明できる
• 既定の Falco が阻止された書き込みを拾えない理由（open_write の fd.num>=0）を説明できる
• 阻止された書き込みを検知するカスタムルールを書ける（evt.res = EROFS 版と evt.rawres < 0 版の 2 通り）
• rule_matching: first（先勝ち）によって、広いルールが具体的なルールを潰すことを説明・再現できる
• PSS Restricted が readOnlyRootFilesystem を要求しないことを説明できる
• コンテナの実行時不変性を自分で実装できる（ルートを塞ぎ、必要な穴だけ emptyDir で開ける）
• 検知を人に届ける経路を組み、送信が成功しても届かない設計があることを実例で示せる

本回の起点#

起点は第16回の完了状態です。Falco は稼働しており、監査ログは撤去済みです。

本回で行き来するホスト#

点の検知から面の網羅へ —— なぜ CKS は 6 つの面を挙げるのか#

第15回の Falco は syscall（コンテナ内の挙動）を、第16回の監査ログは Kubernetes API への操作を見ます。どちらも強力ですが、守備範囲が違います。そして攻撃は 1 つの面だけを通りません。 侵入・横展開・持ち出しは、それぞれ別の場所に痕跡を残します。

CKS の公式コンピテンシー D6 は、検知の対象を次のように列挙しています。

Detect threats within physical infrastructure, apps, networks, data, users and workloads

物理インフラ / アプリ / ネットワーク / データ / ユーザ / ワークロードの 6 つです。本回ではこの 6 つを「面」と呼びます。面とは、攻撃者が触れる場所の分類です。ある道具が 1 つの面をどれだけ深く見ていても、別の面は見えません。Falco と監査ログの 2 つだけでは、6 面のうち埋まらない面が残ります。

先頭の physical を落とさないことが重要です。 Infrastructure 面は「クラスタのコンポーネント」だけでなく、物理・ノード層までを指します。だからこそ 第2回の kube-bench と 第6回・第7回の OS 堅牢化が、この面に割り当たります。

6 面 × 観測手段の実機棚卸し#

第2回から第16回までで導入したものを、6 面の上に並べ直します。下の表は概念図ではなく、このラボの現在の実機状態です。

この表の読み方は 3 つです。

1. 常駐か、都度実行か。 kube-bench と Trivy は「打った瞬間のスナップショット」です。逸脱が起きた時刻には気づけません。「Infrastructure 面は kube-bench で見ている」と書いた地図は、実際には「見ようと思えば見られる」でしかありません
2. 記録するか、拒否するか。 NetworkPolicy と PSA は拒否しますが、拒否したこと自体を後から数える手段は別に要ります。本回の主題（防御は検知を生まない）は、ここでも同じ形で現れます
3. 面が埋まっている＝検知できている、ではありません。 次節でこの表の裏返しを点検します

検知の穴を点検する —— 「入れた＝効いている」ではない#

6 面の表は、埋まっている行より埋まっていない行のほうが役に立ちます。 このラボには現在 3 つの穴があります。どれも事故ではなく、設計判断の結果として今こうなっているものです。

穴①: Users 面が空#

第16回で Audit Policy を有効化し、回の終わりに撤去しました。その結果、「誰が何をしたか」を後から追う手段が現在ゼロです。第16回で読んだ pods/exec の記録も、今このラボには残りません。

実行コマンド（k8s-cp-01・root）：

# grep -c audit /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果（0 件——監査ログは有効化されていません）：

0

穴②: Gatekeeper は動いているが、何も強制していない#

helm release（gatekeeper 3.23.0）も CRD も webhook も存在します。それでも、強制の実体は空です。

実行コマンド（k8s-ops・developer）：

$ kubectl get constrainttemplates
$ kubectl get constraints -A
$ kubectl get validatingadmissionpolicy

実行結果（3 つとも空。ただし返り方は 2 種類あります）：

No resources found
error: the server doesn't have a resource type "constraints"
No resources found

ConstraintTemplate 0 本・Constraint 0 本です。これは第8回の演習末尾で意図的に撤去したためで、事故ではありません。撤去には理由がありました——ポリシーを残したままにすると、以降の回で Pod を作るたびに本題と無関係な拒否が起きて、環境が学習の邪魔をするからです。

問題は、判断そのものではなく、判断を覚えていられないことです。 撤去したことを忘れていれば、helm list -A に gatekeeper が並んでいるのを見て「ポリシーは効いている」と読みます。

同じことが署名検証にも当てはまります。ImagePolicyWebhook は第14回の末尾で撤去済みです。cosign と bom のバイナリは /usr/bin/ に残っていますが、それは CI 時点の道具であって、実行中のクラスタを見張るものではありません。

→ Workloads 面で実際に効いているのは PSA だけです。

穴③: Data 面は「保存時」だけ守られている#

第9回の etcd 暗号化は保存時のデータを守ります。ディスクを持ち出されても Secret は読めません。しかし「Secret を誰が読んだか」は、監査ログが無い今は追えません。 第16回で設計した「secrets は Metadata で記録する」というルールは、監査ログがあって初めて意味を持ちます。

点検の作法（読者が持ち帰るもの）#

撤去を判断した本人でも、3 回後には忘れます。 だから記憶ではなくコマンドで点検します。 下の 5 行は、自分のクラスタでそのまま使えます。

実行時不変性を、検知の観点で読み直す#

コンテナの実行時不変性（immutability at runtime）とは、起動後のコンテナのファイルシステムを書き換えられない状態にすることです。 攻撃者がコンテナに入っても、ツールをダウンロードして置くことも、バイナリを差し替えることもできなくなります。

fanclub-backend の securityContext は次のとおりです（実機値）。

実行コマンド（k8s-ops・developer）：

$ kubectl get deploy -n fanclub fanclub-backend -o jsonpath='{.spec.template.spec.containers[?(@.name=="backend")].securityContext}'

実行結果：

{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true,"runAsNonRoot":true,"runAsUser":10001}

Pod レベルには seccompProfile が付いています（第6回で追加したものです）。

{"seccompProfile":{"type":"RuntimeDefault"}}

ルートを全部塞いで、必要な穴だけ 2 つ開ける#

readOnlyRootFilesystem: true にすると、アプリが書きたい場所も塞がります。そこで、書く必要のあるパスにだけ emptyDir をマウントします。 backend には 2 つあります。

実行コマンド（k8s-ops・developer）：

$ kubectl get deploy -n fanclub fanclub-backend -o jsonpath='{range .spec.template.spec.containers[?(@.name=="backend")].volumeMounts[*]}{.name}{" "}{.mountPath}{"\n"}{end}'

実行結果：

applog /var/log/app
payara-tmp /opt/payara/tmp

「ルートを全部塞いで、必要な穴だけ 2 つ開ける」——これが不変性の実装の形です。emptyDir は Pod と寿命を共にするので、Pod が作り直されれば書かれたものは消えます。攻撃者が置いたツールも、Pod の再作成で消えます。

PSS Restricted は readOnlyRootFilesystem を要求しない#

fanclub namespace は enforce / warn / audit すべて restricted です。

実行コマンド（k8s-ops・developer）：

$ kubectl get ns fanclub -o jsonpath='{.metadata.labels}'

実行結果（抜粋）：

{"pod-security.kubernetes.io/enforce":"restricted","pod-security.kubernetes.io/warn":"restricted","pod-security.kubernetes.io/audit":"restricted"}

それでも、readOnlyRootFilesystem を持たない Pod は何の警告も出ずに admit されます（やってみよう① ステップ 5 で実際に作ります）。公式の Restricted プロファイル要件一覧（https://kubernetes.io/docs/concepts/security/pod-security-standards/）に readOnlyRootFilesystem は列挙されていません。 Restricted が要求するのは allowPrivilegeEscalation: false / capabilities.drop: [ALL] / runAsNonRoot / seccompProfile などであって、ルートファイルシステムの読み取り専用化は含まれません。

防御は検知を生まない —— 既定 25 ルールに write 系が 1 本もない#

ここからが本回の背骨です。「書けなかった」という事実は、既定の Falco には残りません。

第15回で確認したとおり、Falco の既定ルールは 25 本です。その一覧に Write below etc / Write below root / Write below binary dir は含まれません。

Directory traversal monitored file read
Read sensitive file trusted after startup
Read sensitive file untrusted
Run shell untrusted
System user interactive
Terminal shell in container
Contact K8S API Server From Container
Netcat Remote Code Execution in Container
Search Private Keys or Passwords
Clear Log Activities
Remove Bulk Data from Disk
Create Symlink Over Sensitive Files
Create Hardlink Over Sensitive Files
Packet socket created in container
Redirect STDOUT/STDIN to Network Connection in Container
Linux Kernel Module Injection Detected
Debugfs Launched in Privileged Container
Detect release_agent File Container Escapes
PTRACE attached to process
PTRACE anti-debug attempt
Find AWS Credentials
Execution from /dev/shm
Drop and execute new binary in container
Disallowed SSH Connection Non Standard Port
Fileless execution via memfd_create

この一覧の読み方です。 既定ルールは「読まれると困るもの」（機密ファイルの read・鍵の探索）と「実行されると困るもの」（シェル・netcat・カーネルモジュール）に寄っています。書き込みは、成功しても失敗しても、既定では見えません。

open_write マクロが阻止された書き込みを拾えない理由#

既定に無いなら自分で書けばよい——そう考えて、既定のマクロ open_write を素直に使うと、やはり拾えません。実機のマクロ定義を見ます。

- macro: open_write
  condition: (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0)

fd.typechar はファイルディスクリプタの種別を表す 1 文字で、'f' は通常ファイルを意味します。問題は最後の fd.num>=0 です。open が成功したときだけ、カーネルはファイルディスクリプタ番号（0 以上の整数）を返します。 readOnlyRootFilesystem に阻まれた open は失敗するので、fd.num は -1 になります。

阻止された書き込みを拾う 3 通りの条件#

では何を書けばよいか。実機で確認したところ、次の 3 通りはいずれも同じイベントにマッチします。

• evt.res は syscall の結果を文字列で表したものです。成功なら SUCCESS、失敗ならエラー名（EROFS / EACCES など）が入ります
• evt.rawres は syscall が返した生の戻り値です。成功なら 0 以上、失敗なら負の errno になります
• -30 が -EROFS である理由: Linux の errno 30 が EROFS（Read-only file system）です。syscall は失敗時に errno へ負号を付けた値を返すので -30 になります
• %fd.name は open が失敗していても対象パスが取れます（/tmp/attacker-tool）。%evt.arg.name も同じ値を返します。「どこへ書こうとしたか」は失敗しても分かります

本回で採用するのは evt.res = EROFS です。 3 つのうち最も具体的で、「不変性の防御が実際に働いた瞬間」だけを拾えるからです。evt.rawres < 0 と fd.num < 0 は、権限不足（EACCES）・ファイル不在（ENOENT）まで拾ってしまいます。

やってみよう①：既定では無音であることを確かめ、カスタムルールで可視化する#

ここまでの話を、自分の手で再現します。「拾えない → もっと拾えない → 拾える」の 3 段を順に踏みます。

実測では、helm upgrade 1 回あたり「コマンド発行から DaemonSet のローリング完了まで 126 秒」でした（5 ノード）。本回で打つ helm upgrade は合計 10 回です（やってみよう① で 2 回・やってみよう② で 4 回・やってみよう③ で 4 回）。合計 20 分前後は、この待ち時間に使います。

ステップ1：既存の防御を読む#

前節で実行した 2 つのコマンド（securityContext と volumeMounts）を、まだ打っていなければここで打ちます。コンテナ名は backend です。これから何を「検知したい」のかを、先に自分の目で確認します。

ステップ2：Falco のログを流しながら、書き込みを試す#

別ターミナルで Falco のログを --tail=0 で開いておきます（第15回の作法）。backend Pod が動いているノードの Falco Podを選びます。

実行コマンド（k8s-ops・developer・監視用ターミナル）：

$ kubectl logs -n falco <backend Pod と同じノードの falco Pod 名> -c falco --tail=0 -f

もう一方のターミナルで、ルートへの書き込みを試します。

実行コマンド（k8s-ops・developer・作業用ターミナル）：

$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'

実行結果（防御は働きました）：

touch: cannot touch '/evil.txt': Read-only file system
command terminated with exit code 1

このとき Falco 側に出るのは、第15回で作ったカスタムシェルルール 1 本だけです（sh -c を実行しているのでシェル起動として検知されます）。書き込み試行そのものは 0 件です。

ステップ3：open_write 版のルールを書いて、それでも拾えないことを確かめる#

~/falco-lab/custom-values.yaml の customRules.rules-fanclub.yaml に、マクロ 1 本とルール 1 本を追記します（第15回の最終形は壊しません）。

追記する内容（customRules.rules-fanclub.yaml の末尾へ）：

    - macro: fanclub_ns_container
      condition: (container and k8s.ns.name = "fanclub")

    - rule: Write in fanclub via open_write
      desc: open_write マクロで書き込みを検知しようとしたもの
      condition: open_write and fanclub_ns_container
      output: >
        open_write 版で検知 (proc=%proc.name file=%fd.name fdnum=%fd.num
        pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, immutability, cks]

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s

ローリング再起動が終わったら、ルールが読み込まれたことを必ず確認します。

実行コマンド（k8s-ops・developer）：

$ kubectl logs -n falco <falco Pod 名> -c falco --tail=20 | grep -E 'Loading rules|schema validation'

実行結果：

Loading rules from:
   /etc/falco/falco_rules.yaml | schema validation: ok
   /etc/falco/rules.d/rules-fanclub.yaml | schema validation: ok

ok を確認してから、ステップ 2 の touch /evil.txt を再実行します。結果は 0 件のままです。 ルールは読み込まれ、条件は文法的に正しく、それでも 1 件も出ません——open_write の内側の fd.num>=0 が外れないからです。

ステップ4：evt.res = EROFS 版に書き換えて、可視化する#

open_write マクロを使わず、条件を自分で全部書きます。 ステップ 3 のルールはこの後の比較で使うので残したまま、もう 1 本を追記します。

追記する内容（customRules.rules-fanclub.yaml の末尾へ）：

    - rule: Blocked write in immutable container
      desc: readOnlyRootFilesystem に阻まれた書き込み試行
      condition: >
        evt.type in (open,openat,openat2)
        and evt.is_open_write=true
        and fanclub_ns_container
        and evt.res = EROFS
      output: >
        不変コンテナへの書き込みが阻止された (proc=%proc.name file=%fd.name
        res=%evt.res rawres=%evt.rawres fdnum=%fd.num
        container=%container.name pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, immutability, cks]

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'

実行結果（Falco のログ・今度は発火します）：

12:49:35.156388015: Warning 不変コンテナへの書き込みが阻止された (proc=touch file=/evil.txt res=EROFS rawres=-30 fdnum=-1 container=backend pod=fanclub-backend-56875d65c9-4fdf8 ns=fanclub) container_id=232e20b98e4e container_name=backend container_image_repository=k8s-registry:5000/fanclub-backend container_image_tag=0.4.1 k8s_pod_name=fanclub-backend-56875d65c9-4fdf8 k8s_ns_name=fanclub

res=EROFS / rawres=-30 / fdnum=-1 が出力に載りました。 防御が働いた瞬間が、初めて記録に残りました。

ステップ5：対照実験（書ける場所で取る）#

不変性のある / なしで結果が変わることを確かめます。比較対象の Pod を fanclub namespace に作ります。

マニフェスト（k8s-ops 上・~/falco-lab/mutable-probe.yaml・PSA restricted を通る最小形）：

apiVersion: v1
kind: Pod
metadata:
  name: mutable-probe
  namespace: fanclub
spec:
  restartPolicy: Never
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: probe
      image: busybox:1.37
      command: ["sleep", "3600"]
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

実行コマンド（k8s-ops・developer）：

$ kubectl apply -f ~/falco-lab/mutable-probe.yaml

実行結果（警告 1 行も出ずに作成されます）：

pod/mutable-probe created

このマニフェストには readOnlyRootFilesystem がありません。 それでも enforce: restricted の namespace に通ります——PSS Restricted が不変性を要求していない証拠です。

3 つの対象で、同じパスへの書き込みを比べます。

実行コマンド（k8s-ops・developer）：

$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /tmp/attacker-tool'
$ kubectl exec -n fanclub mutable-probe -c probe -- sh -c 'touch /tmp/attacker-tool; ls -l /tmp/attacker-tool'
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /opt/payara/tmp/ok.txt; ls -l /opt/payara/tmp/ok.txt'

実行結果（2 行目・不変性が無ければ書けます）：

-rw-r--r--    1 10001    root             0 Aug  2 12:50 /tmp/attacker-tool

ステップ5.5：対照 Pod を「不変」にする —— 不変性を自分の手で実装する#

本回で唯一、読者が不変性を書く場面です。 公式コンピテンシー Ensure immutability of containers at runtime は、ここで満たします。backend 本体には一切触りません（本番相当のワークロードを演習で書き換えないためです）。所要は 3〜5 分で、helm upgrade は不要です。

1. readOnlyRootFilesystem: true を足して作り直す

マニフェスト（~/falco-lab/mutable-probe.yaml を書き換え・コンテナの securityContext に 1 行追加）：

apiVersion: v1
kind: Pod
metadata:
  name: mutable-probe
  namespace: fanclub
spec:
  restartPolicy: Never
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: probe
      image: busybox:1.37
      command: ["sleep", "3600"]
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

実行コマンド（k8s-ops・developer）：

$ kubectl delete pod -n fanclub mutable-probe
$ kubectl apply -f ~/falco-lab/mutable-probe.yaml
$ kubectl exec -n fanclub mutable-probe -c probe -- sh -c 'touch /tmp/attacker-tool'

実行結果：

touch: /tmp/attacker-tool: Read-only file system
command terminated with exit code 1

Falco の出力も入れ替わります。 直前まで fdnum=3 で open_write 版が拾っていたものが、res=EROFS rawres=-30 fdnum=-1 になり、EROFS 版が拾います。 ルールは 1 文字も変えていないのに、出力するルールが変わりました——変えたのは Pod の securityContext だけです。

実行結果（Falco のログ）：

12:52:03.942564162: Warning 不変コンテナへの書き込みが阻止された (proc=touch file=/tmp/attacker-tool res=EROFS rawres=-30 fdnum=-1 container=probe pod=mutable-probe ns=fanclub) container_id=bcde1d08085c container_name=probe container_image_repository=docker.io/library/busybox container_image_tag=1.37 k8s_pod_name=mutable-probe k8s_ns_name=fanclub

2. /tmp に emptyDir をマウントして、必要な穴を開ける

マニフェスト（~/falco-lab/mutable-probe.yaml を書き換え・volumeMounts と volumes を追加）：

apiVersion: v1
kind: Pod
metadata:
  name: mutable-probe
  namespace: fanclub
spec:
  restartPolicy: Never
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: probe
      image: busybox:1.37
      command: ["sleep", "3600"]
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: probe-tmp
          mountPath: /tmp
  volumes:
    - name: probe-tmp
      emptyDir: {}

実行コマンド（k8s-ops・developer）：

$ kubectl delete pod -n fanclub mutable-probe
$ kubectl apply -f ~/falco-lab/mutable-probe.yaml
$ kubectl exec -n fanclub mutable-probe -c probe -- sh -c 'touch /tmp/attacker-tool; ls -l /tmp/attacker-tool'

実行結果（再び書けるようになります）：

-rw-r--r--    1 10001    root             0 Aug  2 12:52 /tmp/attacker-tool

3. backend に回収する

今やった 2 段が、そのまま fanclub-backend の姿です。 ルートを readOnlyRootFilesystem: true で塞ぎ、書く必要のある /var/log/app（applog）と /opt/payara/tmp（payara-tmp）にだけ emptyDir を開ける——この作業を第1巻の時点で済ませた結果が、いま backend に入っている設定です。

試験で「コンテナを不変にせよ」と言われたら、この 2 段を書きます。 1 段目だけだとアプリが起動に失敗することがあり、どこに書いているかを kubectl logs のエラーから読み取って、2 段目で穴を開ける——という順序になります。

ステップ6：後始末#

対照 Pod を削除します。カスタムルールは次の演習で使うので残します（回全体の後始末は やってみよう③ ステップ 6 で行います）。

実行コマンド（k8s-ops・developer）：

$ kubectl delete pod -n fanclub mutable-probe --ignore-not-found

やってみよう②：rule_matching: first —— 広いルールが具体的なルールを潰す#

第15回で、/etc/falco/falco.yaml の設定を読んだときに rule_matching: first（最初にマッチしたルールで打ち切る）を確認しました。ここでは、それを自分で書いた 2 本のルールで実際に起こします。

実行コマンド（k8s-ops・developer・設定値の再確認）：

$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -n 'rule_matching' /etc/falco/falco.yaml

実行結果（106 行目）：

106:rule_matching: first

第15回で扱った分と、本回で新しく踏み込む分#

観測できる事実はこうです——1 つのイベントに対して、最初にマッチした 1 本だけが発火します。 そして評価の順番を決めるのは、ルールを定義した順です。したがって広いルールを前に置くと、後ろの具体的なルールが警告もエラーも出さずに発火しなくなります。

ステップ1：広いルールを、具体的なルールの前に置く#

Blocked write in immutable container の前に、evt.rawres < 0 の広いルールを追加します。

追記する内容（Blocked write in immutable container の直前へ）：

    - rule: Any failed open in container
      desc: 失敗した open すべて（広いルール）
      condition: >
        evt.type in (open,openat,openat2)
        and evt.is_open_write=true
        and container
        and evt.rawres < 0
      output: >
        失敗した open (proc=%proc.name file=%fd.name res=%evt.res rawres=%evt.rawres
        pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, immutability, cks]

ステップ2：広いほうだけが発火する#

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'

実行結果（Falco のログ・広いほうだけが出ます）：

12:56:51.136683618: Warning 失敗した open (proc=touch file=/evil.txt res=EROFS rawres=-30 pod=fanclub-backend-56875d65c9-4fdf8 ns=fanclub) container_id=232e20b98e4e container_name=backend container_image_repository=k8s-registry:5000/fanclub-backend container_image_tag=0.4.1 k8s_pod_name=fanclub-backend-56875d65c9-4fdf8 k8s_ns_name=fanclub

Blocked write in immutable container は 0 件です。エラーも警告も出ません。schema validation は ok のままで、ルールは正しく読み込まれています。 それでも出ません。

ステップ3：2 本の順序だけを入れ替える#

Any failed open in container を Blocked write in immutable container の後ろへ移します。条件は 1 文字も変えません。 変えるのは並び順だけです。

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'

実行結果（今度は具体的なほうだけが出ます）：

12:58:56.609767046: Warning 不変コンテナへの書き込みが阻止された (proc=touch file=/evil.txt res=EROFS rawres=-30 fdnum=-1 container=backend pod=fanclub-backend-56875d65c9-4fdf8 ns=fanclub) container_id=232e20b98e4e container_name=backend container_image_repository=k8s-registry:5000/fanclub-backend container_image_tag=0.4.1 k8s_pod_name=fanclub-backend-56875d65c9-4fdf8 k8s_ns_name=fanclub

ステップ4：rule_matching: all という選択肢#

Falco 0.36.0 以降は rule_matching: all を選べます。同一イベントにマッチしたルールが互いを打ち切らなくなり、該当するもの全部が発火します。 公式は代償として CPU 使用の増加を挙げています（ドキュメント由来の記述で、本ラボでの実測値ではありません）。

values に書く形（~/falco-lab/custom-values.yaml へ追記）：

falco:
  rule_matching: all

falco: は customRules: と同じトップレベルに置きます（falco.yaml に流し込まれるキーがこの下にまとまっています）。

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -n 'rule_matching' /etc/falco/falco.yaml
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'

実行結果（falco.yaml の同じ 106 行目が書き換わります）：

106:rule_matching: all

実行結果（Falco のログ・2 本とも出ます）：

13:01:51.804467722: Warning 不変コンテナへの書き込みが阻止された (proc=touch file=/evil.txt res=EROFS rawres=-30 fdnum=-1 container=backend pod=fanclub-backend-56875d65c9-4fdf8 ns=fanclub)
13:01:51.804467722: Warning 失敗した open (proc=touch file=/evil.txt res=EROFS rawres=-30 pod=fanclub-backend-56875d65c9-4fdf8 ns=fanclub)

2 行のタイムスタンプが 13:01:51.804467722 でナノ秒まで一致しています。 別々のイベントが 2 回起きたのではなく、1 つのイベントから 2 本のアラートが出たことの証拠です。

CPU については、本ラボの規模では差を読み取れませんでした。 kubectl top pod -n falco の実測は切替前が 5m〜16m、切替 60 秒後が 5m〜13m で、ゆらぎの範囲に収まっています。 公式が挙げる CPU 増は、ルール本数とイベント量がラボよりはるかに多い環境での話だと考えてください。「本番で試す前に負荷をかけて測る」——それが公式の推奨する手順です。

なお chart の values では、rule_matching の説明に [Incubating]（開発途上）と書かれています。本番で採用する前に、この表記が外れているかを確認します。

ステップ5：first に戻す#

本ラボの既定は first のままにします。 ステップ 4 で追加した falco: の 2 行を ~/falco-lab/custom-values.yaml から削除し、もう一度反映します。ステップ 3 で入れ替えた順序はそのまま（具体的なものが先・広いものが後）にしておきます。

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -n 'rule_matching' /etc/falco/falco.yaml

実行結果：

106:rule_matching: first

運用の原則はこうです——具体的なルールを先に、広いルールを後に並べます。 Audit Policy の評価順（第16回）とまったく同じ形です。catch-all を先頭に置くと、後ろが全部無意味になります。

この論点が効く場面#

第15回の override: condition: replace と、本回の「順序で潰れる」は別の話です。 混同しないよう、並べて対比します。

アラート設計 —— 届かない検知に意味はない#

ルールが書けるようになると、次は「これを誰に、どうやって届けるか」という設計の問題になります。Falco Pod のログに出ているだけでは、誰も見ていません。

ノイズは priority では落とせない#

やってみよう① ステップ 3 で入れた open_write 版のルールは、実運用ではノイズ源になります。 fanclub namespace には PostgreSQL が居るからです。PostgreSQL だけで 60 秒ごとに 4 件発火します。

/var/lib/postgresql/data/pgdata/postmaster.pid
/dev/shm/PostgreSQL.1535092568
/var/lib/postgresql/data/pgdata/base/16384/2601
/var/lib/postgresql/data/pgdata/base/16384/1259

すべて priority が Warning です。 したがって、出力先で minimumpriority: warning を設定しても1 件も落ちません。 「重要度でしきい値を切ればノイズは減る」という発想は、ここでは効きません。

falcosidekick の minimumpriority は、出力先ごとにしかありません。 chart 0.12.1 の values を数えると minimumpriority は 64 箇所あり、そのすべてが config.<出力先>.minimumpriority の形です。config 直下に「全体のしきい値」を置くキーはありません。 全体で絞りたい場合は、falcosidekick ではなく Falco 本体の priority（/etc/falco/falco.yaml の 101 行目・実機は debug ＝すべて出す）で絞ります。

検知は二系統ある#

通知先の分け方#

本回で作った Blocked write in immutable container は「日次で足りる」側です。 防御は既に働いているので、緊急に人を起こす必要はありません。ただし件数の傾向が変わったら調べます——普段 0 件のものが 1 日 100 件になったなら、誰かが何かを試しています。

本ラボでの経路の選択#

Slack へ送る場合の values は次の形です。本ラボでは alma-proxy の whitelist に hooks.slack.com が無いため到達しません（whitelist は 44 行のまま変えません）。

falcosidekick:
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/XXXXXXXXX/YYYYYYYYY/ZZZZZZZZ"
      minimumpriority: "warning"
      outputformat: "all"

やってみよう③：falcosidekick を入れる —— Loki には届き、Alertmanager には届かない#

falcosidekick は、Falco のアラートを受け取って各種の出力先へ転送するコンポーネントです。Falco 本体は「検知」だけを行い、「どこへ送るか」は falcosidekick が担います。

ステップ1：導入 —— helm repo add は要らない#

chart 9.1.0 には falcosidekick が同梱されています（falco/charts/falcosidekick/）。第15回で判明した「helm repo add（github.io）が Forbidden になる」問題を踏まずに、values だけで入ります。

values（~/falco-lab/custom-values.yaml の 末尾へ追記・customRules: と同じ階層）：

falcosidekick:
  enabled: true
  replicaCount: 1
  config:
    loki:
      hostport: "http://loki.monitoring:3100"
    alertmanager:
      hostport: "http://kube-prometheus-stack-alertmanager.monitoring:9093"

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status deploy/falco-falcosidekick -n falco --timeout=300s
$ kubectl get svc -n falco

実行結果：

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
falco-falcosidekick   ClusterIP   10.106.39.222   <none>        2801/TCP,2810/TCP   2m9s

Falco 側の設定は chart が自動で配線します。 実機の /etc/falco/falco.yaml を見ると、http_output（35 行目）が falcosidekick の Service を向き、json_output: true（54 行目）が有効になっています。values に自分で書く必要はありません。

ステップ2：Loki へは既定のまま通る#

先ほどの touch /evil.txt をもう一度打ってから、falcosidekick のログを読みます。

実行コマンド（k8s-ops・developer）：

$ kubectl logs -n falco deploy/falco-falcosidekick --tail=20

実行結果（Loki は 204 で受け取っています）：

2026/08/02 13:05:56 [INFO]  : Loki - POST OK (204)

Loki の endpoint は既定（/loki/api/v1/push）のまま通ります。 Grafana で中身を確認します。Grafana は ClusterIP のみで外部公開していないので、kubectl port-forward でつなぎます。

実行コマンド（k8s-ops・developer）：

$ kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

Service 名は kubectl get svc -n monitoring で確認できます（実機は Grafana が kube-prometheus-stack-grafana の 80/TCP、Alertmanager が kube-prometheus-stack-alertmanager の 9093/TCP、Loki が loki の 3100/TCP です）。これらは第2巻で構築した監視基盤で、本回はそこへ相乗りします。

Grafana の Explore で Loki データソースを選び、LogQL（Loki のクエリ言語。{ラベル="値"} でログの流れを選びます）で引きます。

{source="syscall"}

ここまでで「届く」経路が 1 本できました。 Falco のログを人が読みに行くのではなく、ログ基盤の側で横断して検索できます。

ステップ3：Alertmanager は chart 既定だと全件 410 で落ちる#

同じログの中に、Alertmanager 側のエラーが並んでいます。

実行結果（kubectl logs -n falco deploy/falco-falcosidekick より）：

2026/08/02 13:05:56 [ERROR] : AlertManager - unexpected Response (410)
2026/08/02 13:05:56 [ERROR] : AlertManager - 410 Gone

原因は chart 既定の endpoint: "/api/v1/alerts" です。本ラボの Alertmanager は v0.32.1 で、v1 API は撤去済みです。endpoint を明示して /api/v2/alerts にすると通ります。

values（alertmanager の下へ endpoint を追加）：

falcosidekick:
  enabled: true
  replicaCount: 1
  config:
    loki:
      hostport: "http://loki.monitoring:3100"
    alertmanager:
      hostport: "http://kube-prometheus-stack-alertmanager.monitoring:9093"
      endpoint: "/api/v2/alerts"

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status deploy/falco-falcosidekick -n falco --timeout=300s
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'
$ kubectl logs -n falco deploy/falco-falcosidekick --tail=20

実行結果（200 が返るようになりました）：

2026/08/02 13:06:52 [INFO]  : AlertManager - POST OK (200)

ステップ4：200 が返っても、誰にも届いていない#

Alertmanager 側にアラートは実在します。

実行コマンド（k8s-ops・developer・別ターミナルで port-forward してから）：

$ kubectl port-forward -n monitoring svc/kube-prometheus-stack-alertmanager 9093:9093
$ curl -s --noproxy '*' 'http://localhost:9093/api/v2/alerts?filter=source%3D%22falco%22' | jq -r '.[].labels.rule' | sort | uniq -c | sort -rn

実行結果（アラートは Alertmanager の中にあります）：

   6850 Contact K8S API Server From Container
     45 Any failed open in container
      4 Write in fanclub via open_write
      1 Shell spawned in fanclub-backend pod
      1 Blocked write in immutable container

合計 6,901 件が入っていました。探しているものは 1 件で、残りはノイズです。 検知を送る前に落とすべきものが、そのまま通知経路に載っている状態です。

それでも誰にも通知は行きません。 kube-prometheus-stack 既定のルーティングは、受け皿が "null" の 1 つだけだからです。

route:
  receiver: "null"
  group_by: [namespace]
  routes:
  - receiver: "null"
    matchers:
    - alertname="Watchdog"
receivers:
- name: "null"

さらに、falcosidekick が付けるラベルには alertname がありません。

container_id / container_image_repository / container_image_tag / container_name /
eventsource / evt_time / hostname / k8s_ns_name / k8s_pod_name / priority /
proc_cmdline / proc_exepath / proc_name / rule / severity / source / tags /
user_name / user_uid

なお severity は Falco の priority から自動でマップされます（Warning → warning）。annotations には description / info / summary（= ルール名）が入ります。形式としては整っています。それでも届きません。

ラベルの顔ぶれはルールごとに変わります。 上の一覧はシェル起動ルールのものです。open 系のルールでは proc_cmdline / proc_exepath / user_name / user_uid が無く、代わりに evt_res / evt_rawres / fd_name が付きます——Falco 側の output に書いたフィールドが、そのままラベルになるからです。Alertmanager 側で「このラベルで振り分ける」と決めるときは、対象のルールがそのフィールドを出力しているかを先に確認します。

ステップ5：何を直せば届くのか#

直す順番を間違えないことが重要です。 「alertname が無いから届かない」ではありません。

① 必須の修正 —— これをやらない限り、何をしても届かない

Alertmanager 側に "null" 以外の receiver と、そこへ落とす route を追加します。 受け皿が "null" しかない限り、alertname を付けても、group_by を直しても、絶対に届きません。 届かない直接原因はここ 1 点です。

kube-prometheus-stack の values に書く形は次のとおりです。本ラボには通知を受け取れる先（Slack / PagerDuty / メールサーバ）が無いため、本回では記法の提示までとします。 到達の実演は、次のステップで扱う Loki 側で行います。

alertmanager:
  config:
    route:
      receiver: "null"
      group_by: [namespace]
      routes:
        - receiver: "falco-alerts"
          matchers:
            - source="falco"
          continue: false
    receivers:
      - name: "null"
      - name: "falco-alerts"
        slack_configs:
          - api_url: "https://hooks.slack.com/services/XXXX/YYYY/ZZZZ"
            channel: "#security-alerts"

要点は 2 つです。source="falco" でマッチする route を、既定の receiver: "null" より先に置くこと。 そしてその route が指す receiver を、"null" 以外として receivers に定義すること。 片方だけでは届きません。route の評価も上から順で先勝ち——Falco のルールや Audit Policy と同じ形です。

② そのうえで質を上げる修正 —— 到達性の問題ではない

falcosidekick 側で alertname に相当するラベルを付けると、group_by が機能し、inhibit_rules も噛むようになります。 ①を済ませた後で効いてくる改善であって、①の代わりにはなりません。

falcosidekick 側の書き方はこうです。

falcosidekick:
  config:
    customfields: "alertname:FalcoAlert"

これは実際に効きます。 ~/falco-lab/custom-values.yaml の falcosidekick.config の直下にこの 1 行を足し、helm upgrade で反映してから touch /evil.txt を打つと、届いたアラートに alertname="FalcoAlert" が付きます。group_by も inhibit_rules も噛むようになります。

実行コマンド（k8s-ops・developer）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status deploy/falco-falcosidekick -n falco --timeout=300s
$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'touch /evil.txt'
$ curl -s --noproxy '*' 'http://localhost:9093/api/v2/alerts?filter=source%3D%22falco%22' | jq -r '[.[].labels.alertname] | unique | @json'

実行結果（ラベルは付きました・null は適用前に届いた分）：

[null,"FalcoAlert"]

③ 選ばないという選択 —— 本ラボの結論

Loki 経由に寄せます。 Alertmanager は「Prometheus が出すアラート」のために置かれています。Falco のイベントは形が違います——ラベル体系（alertname と namespace が前提）・発生頻度（1 秒に何件も出る）・継続時間の概念（Prometheus のアラートは「条件を満たしている間ずっと firing」ですが、Falco のイベントは点です）。無理に載せるより、ログ基盤で受けてダッシュボードで見るほうが素直です。

ステップ6：本回の後始末（回全体）#

falcosidekick と不変性ルールは残します。 第18回（インシデント対応）の検知フェーズが、これを土台にします。第15回で「本回で入れた Falco は残す」と述べたのと同じ方針です。

戻すもの: rule_matching を first へ（やってみよう② ステップ 5 で実施済みであることを再確認します）。

~/falco-lab/custom-values.yaml の最終形です（全量・これが本回の成果物です）。

customRules:
  rules-fanclub.yaml: |-
    - list: fanclub_shell_binaries
      items: [sh, ash, bash, busybox]

    - macro: fanclub_backend_pod
      condition: (k8s.ns.name = "fanclub" and k8s.pod.name startswith "fanclub-backend")

    - rule: Shell spawned in fanclub-backend pod
      desc: fanclub-backend Pod のいずれかのコンテナ内でシェルが起動した
      condition: >
        spawned_process
        and container
        and fanclub_backend_pod
        and proc.name in (fanclub_shell_binaries)
      output: >
        fanclub-backend Pod でシェル起動 (user=%user.name uid=%user.uid proc=%proc.name
        exe=%proc.exepath cmd=%proc.cmdline tty=%proc.tty
        container=%container.name
        image=%container.image.repository:%container.image.tag
        pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, shell, cks]

    - macro: user_expected_terminal_shell_in_container_conditions
      condition: (k8s.ns.name = "fanclub" and k8s.pod.name startswith "fanclub-backend")
      override:
        condition: replace

    - macro: fanclub_ns_container
      condition: (container and k8s.ns.name = "fanclub")

    - rule: Blocked write in immutable container
      desc: readOnlyRootFilesystem に阻まれた書き込み試行
      condition: >
        evt.type in (open,openat,openat2)
        and evt.is_open_write=true
        and fanclub_ns_container
        and evt.res = EROFS
      output: >
        不変コンテナへの書き込みが阻止された (proc=%proc.name file=%fd.name
        res=%evt.res rawres=%evt.rawres fdnum=%fd.num
        container=%container.name pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, immutability, cks]

falcosidekick:
  enabled: true
  replicaCount: 1
  config:
    loki:
      hostport: "http://loki.monitoring:3100"

実行コマンド（k8s-ops・developer・最後の helm upgrade で確定させます）：

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ kubectl rollout status ds/falco -n falco --timeout=300s
$ kubectl exec -n falco <falco Pod 名> -c falco -- cat /etc/falco/rules.d/rules-fanclub.yaml

/etc/falco/rules.d/rules-fanclub.yaml の中身が、上の customRules.rules-fanclub.yaml と一致していれば完了です。schema validation: ok も確認します。

本回を終えたときのラボの状態です。

後始末を終えた状態で touch /evil.txt を打つと、広いルールが消えているので Blocked write in immutable container が単独で出ます。 ここまで来れば、次回の土台が整っています。

暗記必須コマンド（コンテナ不変性 / Falco 検知）#

試験ではどう出るか#

本回の演習 3 本は、いずれも 20 分前後かかります。 CKS の 1 問は 5〜12 分で解く想定なので、この一連がそのまま出題されることはありません。 出るとすれば、次の 2 か所です。

• ルールを 1 本書く部分——「指定された条件でカスタムルールを追加し、発火することを確認せよ」。list / macro / rule の記法と、schema validation: ok の確認までが範囲です
• PSS Restricted と readOnlyRootFilesystem の関係を問う部分——「このコンテナを不変にせよ」に対して、PSA ラベルではなく securityContext を書くのが正解です

6 面の棚卸し・穴の点検・Alertmanager の到達性は、試験の実技よりも実務と KCSA 側で効く知識です。 試験対策として抜き出すなら上の 2 点、実務として持ち帰るなら点検コマンド 5 行、という分け方をします。

「区分」列の見方——CKS 実技 は試験でそのまま手を動かす対象です。実務・KCSA の 3 行は CKS の出題範囲外で（falcosidekick / Alertmanager / Loki はいずれも試験中に参照できるドキュメントを持ちません）、覚える理由は「現場で使うから」と「KCSA の観測性の設問で問われるから」です。 試験直前の暗記時間を配分するときは、上 8 行を優先します。

まとめ#

• CKS が挙げる 6 面（physical infrastructure / apps / networks / data / users / workloads）で検知を棚卸しすると、常駐しているもの・都度実行のもの・空いている面が分かれます
• 本ラボの穴は 3 つです。 Users 面が空（第16回で監査ログ撤去）/ Gatekeeper は Constraint 0 本（第8回で撤去）/ 署名検証は第14回で撤去。Workloads 面で効いているのは PSA だけです
• 防御は検知を生みません。 readOnlyRootFilesystem に阻まれた書き込みは、既定 25 ルールでは 1 件も残りません
• open_write は fd.num>=0 を含むため、阻止された書き込みには使えません。evt.res = EROFS / evt.rawres < 0 / fd.num < 0 のいずれかで書きます
• rule_matching: first は先勝ちです。 広いルールを前に置くと、後ろの具体的なルールがエラーにならないまま発火しなくなります。priority は順序に無関係です
• PSS Restricted は readOnlyRootFilesystem を要求しません。 不変性は securityContext で自分で入れます
• ノイズは priority では落とせません（PostgreSQL の 60 秒 4 件はすべて Warning）。ルールの condition 側で除外します
• 送信の 200 は「届いた」ではありません。 Alertmanager は 200 を返しつつ receiver: "null" で捨てます。ラボで端から端まで通るのは Loki + Grafana です
• 本回も whitelist を 1 行も足していません（44 行のまま・5 回連続です）

理解度チェック（○×形式・全 9 問）#

次の各文が正しいか（○）誤りか（×）を判断してください。下の「解答と解説」を開くと答え合わせができます。

1. CKS 公式コンピテンシーは physical infrastructure / apps / networks / data / users / workloads の 6 つの面にわたる脅威検知を挙げている
2. Falco の既定ルールには、コンテナ内でのファイル書き込みを検知するルールが含まれている
3. open_write マクロは fd.num>=0 を条件に含むため、readOnlyRootFilesystem に阻まれた書き込みは拾えない
4. readOnlyRootFilesystem: true を入れておけば、書き込み試行があったことは自動的に記録される
5. Pod Security Standards の restricted プロファイルは readOnlyRootFilesystem を要求する
6. Falco の既定 rule_matching: first では、同じイベントに複数のルールが該当しても最初にマッチした 1 本しか発火しない
7. ルールの priority を上げると、そのルールが他のルールより先に評価される
8. falcosidekick から Alertmanager へ 200 が返れば、担当者に通知が届いたことになる
9. 出力先の minimumpriority を warning にすれば、PostgreSQL の定期的な書き込みノイズは落とせる

解答と解説

1=○／2=×／3=○／4=×／5=×／6=○／7=×／8=×／9=×

• 問1（6 面）: 公式表記は Detect threats within physical infrastructure, apps, networks, data, users and workloads です。この 6 面の脅威検知は KCSA の出題範囲とも重なります——CKS の実技だけでなく、Kubestronaut 5 冠の 5 つ目にあたる KCSA でも問われる論点です
• 問2（既定 25 ルール）: Write below etc / Write below root / Write below binary dir は既定 25 本に含まれません。書き込みは既定では見えません
• 問3（open_write）: マクロの定義は (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0) です。落としているのは fd.num>=0 のほうで、evt.is_open_write は open が失敗しても true になります。ここを取り違えると原因追及の方向を誤ります
• 問4（防御と検知）: 防御と検知は別の価値です。阻止された open は fd.num=-1 で、既定ルールにも open_write にも引っかかりません。検知したいなら evt.res = EROFS 等の条件を自分で書きます
• 問5（PSS Restricted）: Restricted の要件一覧に readOnlyRootFilesystem はありません。実機でも、不変性なしの Pod が enforce: restricted の namespace に警告なく admit されます
• 問6（先勝ち）: 既定は rule_matching: first で、1 つのイベントに対して発火するのは最初にマッチした 1 本だけです。rule_matching: all に切り替えると全部が発火します——実機では 2 本のアラートのタイムスタンプがナノ秒まで一致し、1 イベントから 2 本出ていることが確かめられます
• 問7（priority）: 公式が「priority は他のルールを上書きしたり発火順序を決めたりするものではない。順序を制御するのは定義順である」と明記しています。CRITICAL にしても順番は変わりません
• 問8（200 と到達）: 200 は「Alertmanager が受け取った」までを意味します。そこから先のルーティングで receiver: "null" に落ちれば、誰にも届きません
• 問9（ノイズ）: PostgreSQL のノイズはすべて Warning です。priority のしきい値では 1 件も落ちません。ルールの condition 側で除外します

次回予告#

第18回「セキュリティインシデント対応 DAIR 実戦」では、第15〜17回で組み上げた検知体制を使って、実際のインシデントに対応します。Detect（Falco アラートの受信と一次評価）→ Analyze（影響範囲の特定）→ Isolate（NetworkPolicy による遮断・証拠保全）→ Recover → Postmortem のフローを通します。本回で確認した「穴」——Users 面が空であること——が、Analyze の段でどう効いてくるかも扱います。

D6 の 5 コンピテンシーが揃いました。Falco（第15回）・監査ログ（第16回）・6 面の地図と不変性・アラート経路（本回）——検知の道具と、その限界の両方が手元にあります。次回は、これらを持って実際のインシデントに向き合います。

→ 詳しくは第18回 セキュリティインシデント対応 DAIR 実戦