Falcoでランタイム検知【CKS第15回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第15回です。前回は SBOM と署名で成果物の出所を確かめ、Admission でクラスタの入口を絞り、最後にその Admission を撤去しました。今回から D6 Monitoring, Logging and Runtime Security（配点 20%） に入ります。D6 の 3 回のうち 1 回目です。

本回の主題は 「動き出した後を見る」です。第12〜14回で作った 4 つの関門をすべて通ったコンテナの中で、シェルが起動したり /etc/shadow が読まれたりしたとき、それを捉えるのが Falco です。捉える対象は syscall なので、アプリケーションの改修は要りません。 ルールを書けば、既存のコンテナをそのままにして検知の網を張れます。

そして本回も、道具が既定のままでは動かないところから始まります。 ただし第13回（Trivy の DB 配布元）・第14回（cosign v3 のフラグ）とは詰まり方が違います。本回は 2 段階で詰まります——①chart の配布元に届かない（helm repo add が Forbidden）②届く経路で入れたら、5 台中 4 台しか起動しない。しかも2 番目は helm install が成功した後に起きます。

Falco 本体は 0.44.1 で、Helm chart は 9.1.0 です。 数字がまったく揃っていないので、「chart のバージョン」と「Falco 本体のバージョン」を混同しないでください。 helm show chart の出力には version: 9.1.0 と appVersion: 0.44.1 が両方載ります。ピン留めするのは chart の側（--version 9.1.0）で、本体のバージョンは chart が決めます。

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

D6 は 5 つのコンピテンシーで構成されます。本回はその 1 つ目を担当します。

残る 4 つは 第16回（監査ログ・攻撃フェーズ）・第17回（6 面の脅威検知・不変性・アラート連携）・第18回（インシデント対応の実戦）で埋まります。本回で入れる Falco は、第17回と第18回が土台として使います。

本回の軸: 見えていないものは、見えていないと分からない#

本回は 4 回、同じ形の失敗をします。 どれも「動いているのに何も出ない」あるいは「成功と表示されるのに終わっていない」という形で現れます。

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

第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）

この回のゴール#

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

• Falco が syscall を見ていることと、modern_ebpf（CO-RE）が外部 probe のダウンロードを不要にする理由を説明できる
• whitelist 方式のプロキシ環境で、chart の配布元を OCI へ選び直せる
• helm install が成功しても DaemonSet が全ノードで起動しているとは限らないことを知り、kubectl get pods -o wide で確かめる習慣を持つ
• Error: could not initialize inotify handler から fs.inotify.max_user_instances に辿り着き、sysctl で直し、/etc/sysctl.d/ で永続化できる
• rule / macro / list の 3 要素と priority 8 段階を理解し、既定 25 本のルールが何をカバーしているかを説明できる
• proc.tty の有無で既定ルールの発火が変わることを知り、tty なしでも検知するカスタムルールを書ける
• chart の customRules が /etc/falco/rules.d/ に置かれることと、watch_config_files による自動リロードを説明できる
• 反映経路が 2 つある（helm upgrade = ローリング再起動 / ConfigMap 直接更新 = 自動リロード）ことを使い分けられる
• container.image.repository で絞ると同じ Pod の sidecar が漏れることを知り、k8s.pod.name で絞る版へ書き直せる
• PSA restricted の namespace で kubectl debug が 3 段階に詰まることを知り、--profile と --custom で通せる
• 誤検知を「待つ」のではなく「起こしてから測る」という手順を取れる
• override で既定ルールのチューニング用マクロを置き換え、対象のノイズだけを消せる

本回の起点#

起点は第14回の完了状態です。

本回で押さえておく起点条件が 5 つあります。

1. falco namespace は存在しません。 Falco も falcoctl も入っていません。本回で作るところから始めます
2. 第14回で入れた ImagePolicyWebhook は撤去済みです。apiserver の --enable-admission-plugins は NodeRestriction のみに戻っています。だから本回で新しいイメージ（Falco の 3 つ）を引いても、許可レジストリの制約に当たりません
3. backend Pod の READY は 2/2 です。内訳は本体 backend（fanclub-backend:0.4.1）+ native sidecar log-shipper（busybox:1.37）の 2 つで、これに起動時だけ動く init コンテナ wait-for-db（busybox:1.37）が 1 つ加わります（init は READY に数えられません）。この構成が演習③の山になります
4. fanclub namespace は PSA enforce: restricted です（第8回）。kubectl debug がそのままでは通りません
5. backend の probe は httpGet（/health/live / /health/ready）です。exec probe ではないので、probe 由来のノイズは出ません——これは検知の実験がやりやすいという意味で有利に働きます

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

Falco は何を見ているか —— syscall とドライバ、「防ぐ層」と「気づく層」#

演習に入る前に、Falco が「何を」「どこで」見ているかを 1 度で押さえます。

「防ぐ層」と「気づく層」#

第2〜14回で作ってきたものは、ほぼすべて「防ぐ層」です。

防ぐ層は「起きなかったこと」を証明できません。 NetworkPolicy が通信を落としたのか、そもそも通信が発生しなかったのかは、ポリシーの側からは分かりません。気づく層は、起きたことを記録します。

そして本回で扱うのは、その気づく層にも「見ていない範囲」があるということです。 Falco は syscall を見るので、syscall を伴わない事象は 1 件も捉えません——たとえば API を叩いて Secret を読む操作は、Pod の中の syscall にはなりません。それは第16回の監査ログの担当です。

Falco は syscall を見る#

Falco（CNCF）は、カーネルが発行する syscall のストリームを受け取り、ルールに合致するものを検知してアラートを出します。「コンテナ内でシェルが起動した（execve）」「/etc/shadow が読まれた（openat）」といった事象を、アプリケーションの改修なしに捉えられます。

第11回の Hubble は ネットワークのフローを見せました。Falco はプロセスとファイルを見ます。 同じ「観測」でも見ている面が違います。第17回で 6 面の地図に並べ直すので、本回は「Apps 面（プロセス・ファイル）」を担当していると覚えておいてください。

ドライバ 3 種と、本ラボで選ばれたもの#

Falco が syscall を捕捉する仕組みをドライバと呼び、3 種類あります。

本ラボは chart 既定の driver.kind: auto のまま入れた結果、modern_ebpf が自動選択されました（実測）。falco-driver-loader init container のログを抜粋します。

├ type: modern_ebpf
├ target: almalinux
├ arch: x86_64
├ kernel release: 6.12.0-211.22.1.el10_2.x86_64
└ repos: https://download.falco.org/driver
INFO  No artifacts needed for the selected driver.

最終行が本ラボにとって決定的です。 repos: の行には https://download.falco.org/driver が出ているのに、No artifacts needed for the selected driver. で終わっています。 つまりこの URL には 1 度もアクセスしていません。

理由は /sys/kernel/btf/vmlinux が存在することです（実測 5,652,577 バイト）。BTF（BPF Type Format・カーネル自身が持つ型情報）があると CO-RE が成立し、カーネルに合わせた成果物を外から取ってくる必要が無くなります。

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

$ ls -l /sys/kernel/btf/vmlinux

実行結果：

-r--r--r--. 1 root root 5652577  8月  2 00:54 /sys/kernel/btf/vmlinux

本書ラボでも当初は「第15回で download.falco.org を whitelist に追加する」と想定していましたが、不要でした。 kmod や ebpf を選んだ場合には要ります。ドライバの選択が、そのままネットワーク要件を決めています。

「auto が何を選んだか」はファイルで確認する#

確定値は Pod 内のファイルに書き出されます（実測）。

/etc/falco/config.d/engine-kind-falcoctl.yaml

中身は engine: kind: modern_ebpf になっています。「auto が何を選んだか」は推測せず、このファイルで確認してください。

/sys/kernel のマウント#

chart 既定の sysfsMountPath: "/sys/kernel" により、/sys/kernel/debug と /sys/kernel/tracing の両方がカバーされます（実機ではどちらも存在します）。個別にマウントを足す必要はありません。

配布元を選び直す —— helm repo add は塞がれているが OCI は通る#

演習①に入る前に、なぜ OCI 経路を使うのかを実測で示します。

まず塞がれていることを確認する#

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

$ helm repo add falcosecurity https://falcosecurity.github.io/charts

実行結果：

Error: looks like "https://falcosecurity.github.io/charts" is not a valid chart repository
or cannot be reached: Get "https://falcosecurity.github.io/charts/index.yaml": Forbidden

curl でも確認します。

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

$ curl -s -o /dev/null -w 'code=%{http_code}\n' https://falcosecurity.github.io/charts/index.yaml

実行結果：

code=000

Forbidden を返しているのは GitHub ではなく Squid です。 code=000 は「HTTP のレスポンスが返ってこなかった」を意味します。alma-proxy の whitelist は traefik.github.io / metallb.github.io / prometheus-community.github.io のように個別に列挙する方式で、falcosecurity.github.io は入っていません。

ここで whitelist に 1 行足すのは、いちばん手軽で、いちばん考えない解決です。

第13回・第14回と同じ判断をする#

第13回で Trivy の DB 配布元が塞がれたとき、whitelist に足すのではなく配布元を選び直しました。 第14回では sigstore の 3 サービス（Fulcio / Rekor / TUF）に到達できませんでしたが、鍵ペア方式で完結させて 1 行も足しませんでした。

本回も同じです。 falcosecurity.github.io は塞がれていますが、.ghcr.io は whitelist の 24 行目に登録済みです。Falco の chart は OCI アーティファクトとしても配布されているので、そちらから取れば足さずに済みます。

whitelist は 3 回連続で 44 行のままです。 出口制御のあるネットワークでは、「足す」は最後の手段であり、最初に検討することではありません。

OCI 経路で chart を確認する#

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

$ helm show chart oci://ghcr.io/falcosecurity/charts/falco

実行結果（抜粋）：

Pulled: ghcr.io/falcosecurity/charts/falco:9.1.0
Digest: sha256:a4e37213d1e97abc1290e026b79728facf1c1160b33935995d30be273ad17fd9
apiVersion: v2
appVersion: 0.44.1

helm show chart に --version を付けないと、そのときの最新版が引かれます。 実測では 9.1.0 が引かれましたが、install するときは必ず --version 9.1.0 でピン留めします。 Digest: の値まで控えておくと、後から「同じものを入れたか」を確認できます。

依存 chart が到達不可の URL を指していても入る#

Falco の chart は 3 つの依存 chart を持ちます。

Chart.lock を開くと repository: https://falcosecurity.github.io/charts と書いてあります。 到達できない URL です。それでも helm install は成功します。

理由は、OCI アーティファクトには依存 chart が同梱（vendored）されているからです。helm dependency update を自分で走らせる場合は Chart.lock の URL を見に行きますが、配布された成果物をそのまま入れる分には取りに行きません。

「設定ファイルに書いてある URL に必ずアクセスする」とは限りません。 到達できない URL を見つけたときは、それが実際に使われる経路かどうかを確かめてから対処してください。

使うイメージ 3 つ#

3 つとも Docker Hub にあり、whitelist は第2巻から登録済みです。レジストリの追加も要りません。

「足すか、選び直すか」の判断#

やってみよう①：Falco を導入し、1 台だけ上がらない事象を切り分ける#

所要時間の目安: 約 15 分（Pod の起動待ちとイメージの pull を含みます）。chart を OCI から入れ、起動していないノードを特定し、原因を追い、直し、永続化します。試験相当の作業（values.yaml に設定を書いて helm upgrade する）なら 3 分です。

この演習が本回でいちばん長いのには理由があります。 本回は「入れて終わり」にしません。 検知の道具は、それ自身が動いていることを確認できないと意味がありません。 5 台のうち 1 台で動いていなければ、そのノードに乗っている Pod は 1 件も監視されていません。 しかもアラートが出ないだけなので、静かなまま気づけません。

ステップ1：現状を確認する#

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

$ kubectl get ns falco

実行結果：

Error from server (NotFound): namespaces "falco" not found

ステップ2：OCI 経路で導入する#

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

$ helm install falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco --create-namespace

実行結果（抜粋）：

Pulled: ghcr.io/falcosecurity/charts/falco:9.1.0
Digest: sha256:a4e37213d1e97abc1290e026b79728facf1c1160b33935995d30be273ad17fd9
NAME: falco
NAMESPACE: falco
STATUS: deployed
REVISION: 1

実測値です。

helm install は 2 秒で返ります。 これは「chart を適用した」だけであって、Pod が起動したという意味ではありません。 Helm の STATUS: deployed を導入完了の合図にしないでください——確認するのは kubectl get pods の側です。

ステップ3：5 台中 4 台しか上がっていないことを発見する#

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

$ kubectl get pods -n falco -o wide

実行結果（実測の要点）：

helm install は成功しています。DaemonSet は 5 ノード分の Pod を作っています。それでも 1 台は動いていません。

第14回の ImagePolicyWebhook では「1 台にしか設定を入れていないので 12 回中 4 回しか効かない」でした。今回は逆で、5 台すべてに配ったのに 1 台だけ効いていません。 方向は違いますが、確かめずに「入った」と判断すると同じ結果になるという点で同じです。

DaemonSet を入れたら -o wide で全ノード分を数えてください。 これは本回に限った話ではありません。

ステップ4：原因を読む#

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

$ kubectl get pods -n falco --no-headers | awk '$3!="Running"{print $1}'

実行結果（実測）：

falco-n6kd2

この Pod を名指しでログを読みます。

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

$ kubectl logs -n falco falco-n6kd2 -c falco --tail=8

実行結果（実測・末尾 8 行）：

Sat Aug 01 16:07:10 2026: [libs]: container: Enabled 'bpm' container engine.
Sat Aug 01 16:07:10 2026: Loading rules from:
Sat Aug 01 16:07:10 2026:    /etc/falco/falco_rules.yaml | schema validation: ok
Sat Aug 01 16:07:10 2026: Hostname value has been overridden via environment variable to: k8s-wl-01
Error: could not initialize inotify handler
Events detected: 0
Rule counts by severity:
Triggered rules by rule name:

エラーは 1 行しかありません。 inotify という単語があるので、カーネルの inotify に関する上限に当たっていると当たりを付けます。その直前まで、ルールの読み込みは成功しています——つまり設定やルールの問題ではありません。

inotify は、ファイルやディレクトリの変更をカーネルがプログラムへ通知する仕組みです（inode notify の略）。監視したいプログラムは「インスタンス」を 1 つ作り、その中に「ウォッチ」を必要なだけ登録します。上限はこの 2 つに別々にかかります。

Falco が inotify を使うのは watch_config_files: true（既定）のためです——設定ファイルとルールファイルの変更を監視して自動リロードするのに使っています。この機能は本回の演習③・④でそのまま使うので、外して回避する道は取りません。

ステップ5：上限と使用量を数える#

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

$ sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches

実行結果：

fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 60255

使用中のインスタンス数は、プロセスが開いているファイルディスクリプタを数えて求めます。

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

# find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | wc -l

実行結果（実測）：

144

上限 128 に対して 144 です。 3 ノードで比べます（実測）。

containerd-shim の数と使用量がきれいに対応しています。 shim の個数は、ノードに載っている Pod の数をそのまま表します。

内訳です（実測）。

containerd-shim は 1 Pod あたり 1 プロセスで、それぞれ 2〜4 インスタンス使います（Pod の構成によって変わります）。1 つあたりの数より、プロセスの数が効きます——つまり Pod が多いノードほど先に枯渇します。

k8s-wl-01 は 144 で、上限 128 を既に超えています。 超えた状態でも既存のプロセスは動き続けますが、新しく inotify を要求したプロセスが失敗します。 そこに Falco が来ました。

だから「Falco を入れたら 1 台だけ上がらない」は、Falco の問題ではありません。 ノードの Pod 密度の問題です。読者の環境では別のノードで起きますし、Pod を減らせば起きません。

max_user_watches は 60,255 で余裕があります（実測）。枯渇しているのは instances のほうです——名前が似ているので取り違えやすいところです。

しかも max_user_watches はノードごとに値が違います。 実測では k8s-cp-01 が 28,471・Workload の 2 台が 60,255 でした。カーネルがメモリ量から自動算出するためです。一方 max_user_instances は全ノード一律 128（ディストロ既定のまま）です。

「自分のノードで打ったら記事と違う数字が出た」となるのは watches のほうで、それは正常です。 見るべきは instances の残り——上限 128 に対して今いくつ使っているか、です。

ステップ6：直す（一時的）#

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

# sysctl -w fs.inotify.max_user_instances=512

実行結果：

fs.inotify.max_user_instances = 512

続けて Pod を作り直します。

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

$ kubectl delete pod -n falco --field-selector spec.nodeName=k8s-wl-01

実測値です。

1 分前後かかるのは、init container が 2 つ動くからです（falco-driver-loader と falcoctl-artifact-install）。CrashLoopBackOff からの復帰ではなく、Pod を作り直しています——sysctl の値は起動時に読まれるので、プロセスを作り直さないと反映されません。

ステップ7：永続化する（この演習を「残す」ための必須手順）#

sysctl -w はメモリ上の値を書き換えるだけで、ノードを再起動すると戻ります。

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

# echo 'fs.inotify.max_user_instances = 512' > /etc/sysctl.d/90-falco-inotify.conf
# sysctl --system

実行結果：

* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/10-map-count.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/90-falco-inotify.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.d/99-zzz-override_cilium.conf ...
* Applying /etc/sysctl.d/k8s.conf ...
* Applying /etc/sysctl.conf ...

既存のファイルに追記しないでください。 /etc/sysctl.d/ には本書ラボの時点で 3 つのファイルがありますが、いずれも出所が違います。

ここに Falco の都合を混ぜると、半年後に「この行は誰が何のために入れたのか」が読めなくなります。 とくに 99-zzz-override_cilium.conf は Cilium が管理しているファイルなので、書き足しても次の helm upgrade で消えることがあります。用途ごとに 1 ファイルを作るのが正しい形です。

>>（追記）ではなく >（上書き）を使う理由も同じところにあります。演習をやり直したときに同じ行が二重に入りません。 設定ファイルを配る操作は、何回打っても同じ状態になる形で書きます。

確認します。

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

$ sysctl fs.inotify.max_user_instances

実行結果：

fs.inotify.max_user_instances = 512

本回で入れた Falco は、第17回と第18回が土台にします。だから残します。

残すということは、ノードを再起動しても動く状態にするということです。 sysctl -w のままにすると、次にノードが再起動したときに 1 台だけ Falco が上がらない状態へ戻ります。 そしてそのときには、本回の記憶は薄れています。

第10回の gVisor は撤去しました。第14回の ImagePolicyWebhook も撤去しました。本回は残します。 判断が違うのは、後続の回が前提にするかどうかという 1 点です。残す判断をしたなら、残せる状態にするまでが作業です。

ステップ8：5 台すべてで Running を確認する#

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

$ kubectl get pods -n falco -o wide

実行結果：

NAME          READY   STATUS    RESTARTS   AGE   NODE
falco-xxxxx   2/2     Running   0          Xm    k8s-cp-01
falco-xxxxx   2/2     Running   0          Xm    k8s-cp-02
falco-xxxxx   2/2     Running   0          Xm    k8s-cp-03
falco-xxxxx   2/2     Running   0          Xm    k8s-wl-01
falco-xxxxx   2/2     Running   0          Xm    k8s-wl-02

READY が 2/2 なのは、1 つの Pod に falco と falcoctl-artifact-follow の 2 コンテナが入っているからです（この後の「falcoctl は 2 つの形で入っている」の節で扱います）。1/1 を期待して見ると、増えているように読めますが正常です。

ステップ9：検知基盤自身の負荷を測る#

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

$ kubectl top pods -n falco

実行結果（実測）：

NAME          CPU(cores)   MEMORY(bytes)
falco-fj44c   5m           112Mi
falco-g5z26   14m          147Mi
falco-kqjrz   11m          154Mi
falco-n9288   5m           106Mi
falco-zk9hd   4m           109Mi

まとめると次のとおりです（実測）。

syscall の drop が 0 件であることを確認しておきます。 Falco はカーネルからのイベントをリングバッファで受け取るので、負荷が高いと取りこぼします。 取りこぼした分はアラートが出ません——つまり「静かだから安全」の 3 つ目の原因になります。

本ラボの規模（111 Pod・5 ノード）では 0 件でした。 本番では定期的に確認する項目です。

演習①のゴール確認#

falcoctl はルールを ghcr.io から取り、cosign で検証している —— 第14回が道具の内側にある#

導入直後に流れているログを読み解きます。第14回で手で打った cosign verify が、ここでは道具の内部で自動的に走っています。

falcoctl が何をしているか#

Falco の Pod には falco 以外に falcoctl が 2 つの形で入っています。

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

$ kubectl logs -n falco <falco Pod 名> -c falcoctl-artifact-install

実行結果（抜粋）：

{"level":"INFO","msg":"Resolving dependencies ..."}
{"level":"INFO","msg":"Installing artifacts","refs":["ghcr.io/falcosecurity/rules/falco-rules:5","ghcr.io/falcosecurity/plugins/plugin/container:0.7.1"]}
{"level":"INFO","msg":"Preparing to pull artifact","ref":"ghcr.io/falcosecurity/rules/falco-rules:5"}
{"digest":"ghcr.io/falcosecurity/rules/falco-rules@sha256:36d143c0ae2d...","level":"INFO","msg":"Verifying signature for artifact"}
{"level":"INFO","msg":"Signature successfully verified!"}
{"directory":"/rulesfiles","level":"INFO","msg":"Artifact successfully installed","name":"ghcr.io/falcosecurity/rules/falco-rules:5","type":"rulesfile"}

2 つの artifact（ルールとプラグイン）を取る順序は、実行のたびに入れ替わります（実測で両方の順序を確認しました）。どちらが先かは気にしなくて構いません。

第14回との接続#

第14回で、読者は cosign generate-key-pair して cosign sign して cosign verify を打ちました。 そのとき扱ったのは自分たちのイメージと自分たちの鍵でした。

ここで起きているのは、同じことを falcoctl が自動でやっているという事実です。ghcr.io/falcosecurity/rules/falco-rules:5 を取ってきて、その署名を検証してから展開しています。

第14回の主題「署名検証は『署名があるか』ではなく『誰の署名か』を見る」がそのまま効いています。 falcoctl が検証しているのは Falco プロジェクトの署名であり、自分たちの鍵ではありません。 道具の中に、Falco プロジェクトを信頼するという判断が埋め込まれています。

つまりサプライチェーンは、道具を入れた時点で 1 段深くなります。 自分たちのイメージに署名しても、その署名を検証する道具自身がどこから来たかという問いは残ります。第14回で「持ち込むもの」と「出すもの」を区別しましたが、ここでは「持ち込んだ道具が、さらに何かを持ち込んでいる」という形になっています。

index には到達できないのに install は成功する#

falcoctl の index は https://falcosecurity.github.io/falcoctl/index.yaml を指しており、これは到達できません（falcosecurity.github.io が whitelist に無いためです）。それでも artifact の取得は成功します。

chart の既定値が、artifact を OCI 参照で直接指定しているため、index を引く必要がありません。index は「falco-rules という名前がどの OCI 参照に対応するか」を調べるためのものであり、参照が最初から書いてあれば不要です。

前節の Chart.lock と同じ構図です——設定に書いてある URL が、必ず使われるとは限りません。 ログに Forbidden が出ていないことを確認したうえで、到達できない URL を放置する判断も成り立ちます。

取得されるもの 2 つ#

アラートに k8s_pod_name と k8s_ns_name が入るのは、container プラグイン 0.7.1 が付けているからです。chart の依存にある k8s-metacollector を有効化しなくても、Pod 名と namespace は出ます。

本回では 3 つの依存 chart をどれも有効化しません。 アラートの転送は第17回の担当です。本回は「検知が出ること」までを扱います。

本回で導入されるもの一覧#

Pod の中で直接確認できます。

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- falco --version

実行結果（実測・末尾 8 行）：

Falco version: 0.44.1
Libs version:  0.25.4
Plugin API:    3.12.0
Engine:        0.62.0
Driver:
  API version:    10.0.0
  Schema version: 4.3.0
  Default driver: 10.2.0+driver

先頭には設定ファイルの読み込み結果が数行出ます（falco --version でも設定を読むためです）。見たいのはこの末尾 8 行です。

既定ルールは 25 本しかない —— rule / macro / list と priority#

演習②に入る前に、ルールの文法と、既定でカバーされている範囲を確認します。

ルールを構成する 3 要素#

priority は 8 段階です。

EMERGENCY > ALERT > CRITICAL > ERROR > WARNING > NOTICE > INFO > DEBUG

本ラボの実測（falco.yaml の設定）です。

rule_matching: first の意味を押さえておきます。 1 つの syscall イベントに複数のルールが当てはまる場合、最初にマッチした 1 本で打ち切られます。 つまり「同じ操作で 2 本のアラートが出る」ことは既定では起きません。

これは演習③で効いてきます——カスタムルールと既定の Terminal shell in container の両方に当てはまる操作をしたとき、どちらか一方しか出ません。 「カスタムルールが効いていない」と読み違えないよう、rules_files の読み込み順と rule_matching を先に確認しておきます。

既定ルールは 25 本#

falco-rules:5 が入れる /etc/falco/falco_rules.yaml（実測 63,642 バイト）に含まれる - rule: は 25 本です（実測）。

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

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -c '^- rule:' /etc/falco/falco_rules.yaml

実行結果：

25

25 本です。 これを多いと見るか少ないと見るかは、何を守りたいかによります。

既定ルールは「どんな環境でも誤検知が出にくいもの」に絞られています。 環境固有の事情（このイメージだけは exec を許す、このプロセスは正常）を知らない状態で配られるので、広く網を張ると誤検知だらけになります。 だから狭く始めて、環境ごとに足していくのが前提の設計です。

「Falco を入れれば検知される」ではなく、「Falco を入れると 25 本の網が張られる。足りない分は自分で書く」が正しい理解です。カスタムルールを書くことは、追加作業ではなく本来の使い方です。

25 本が見ている範囲#

分類してみると、攻撃の流れに沿って並んでいることが分かります——入る（シェル）→ 調べる（機密ファイル）→ 外へ出す（ネットワーク）→ 消す（痕跡）→ 上がる（脱出・カーネル）。第18回の DAIR で扱う攻撃フェーズと対応します。

Terminal shell in container の条件に proc.tty != 0 がある#

演習②の伏線として、この 1 本だけ条件を読みます。

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -A 12 'rule: Terminal shell in container' /etc/falco/falco_rules.yaml

実行結果（実測）：

- rule: Terminal shell in container
  desc: >
    A shell was used as the entrypoint/exec point into a container with an attached terminal. Parent process may have
    legitimately already exited and be null (read container_entrypoint macro). Common when using "kubectl exec" in Kubernetes.
    Correlate with k8saudit exec logs if possible to find user or serviceaccount token used (fuzzy correlation by namespace and pod name).
    Rather than considering it a standalone rule, it may be best used as generic auditing rule while examining other triggered
    rules in this container/tty.
  condition: >
    spawned_process
    and container
    and shell_procs
    and proc.tty != 0
    and container_entrypoint

grep -A 12 なので、ここまでが 12 行分です。 output と priority は続きにあります（-A の数を増やせば読めます）。本節で見たいのは condition の 5 行です。

ルール名は Terminal shell in container です。 「Shell in container」ではなく 「Terminal shell」——端末が付いているシェルを検知する、と名前に書いてあります。

条件にも proc.tty != 0 があります。 proc.tty は制御端末のデバイス番号で、端末が付いていなければ 0 になります。つまり kubectl exec に -it を付けなければ、このルールには当たりません。

これは実装の不備ではなく、意図された絞り込みです。 コンテナの中では、アプリケーションが子プロセスとしてシェルを起動することが日常的にあります（起動スクリプト・ヘルスチェック・cron）。それらを全部拾うと誤検知だらけになるので、「人が対話的に入ってきた」ものだけに絞っています。

絞り込みは、常に「見なくなるもの」を作ります。 次の演習で、その見なくなった側を確認します。

本回で使う主なフィールド#

やってみよう②：kubectl exec が検知されないことを確認する#

所要時間の目安: 約 6 分。既定ルールに対して 2 通りの kubectl exec を打ち、アラートの有無を比べます。試験相当の作業（検知されるか確認する）なら 3 分です。

読者が最初につまずくのはここです。 記事や公式ドキュメントの手順どおりに kubectl exec を打っても、アラートが 1 件も出ません。 そこで「Falco が壊れている」「導入に失敗した」と考えて、動いているものを疑って時間を使います。

本演習は、先に「出ない」ことを確認してから、「出る」ことを確認します。 順序が逆だと学びになりません。

ステップ0：アラートの見方を用意する#

実行コマンド（k8s-ops・developer・別の端末で流しっぱなしにします）：

$ kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco -f --prefix --tail=0

--prefix を付けると、どの Pod が出したアラートかが行頭に付きます。 DaemonSet なので 5 台分のログが混ざります——アラートが「どのノードで起きたか」は、この接頭辞で分かります。

--tail=0 で「これ以降」に絞ります。 起動直後のログを同時に流すと、falcoctl の取得ログや起動時の誤検知（演習④で扱います）が混ざって読みにくくなります。

ステップ1：素の kubectl exec を打つ（tty なし）#

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

$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'id'

実行結果：

uid=10001(appuser) gid=10001(appuser) groups=10001(appuser)

このときの Falco のログ：

（1 件も出ません）

コンテナの中でシェルが起動して、コマンドが実行されて、結果が返ってきました。それでも Falco は 1 件も出しません。

原因は前節で読んだとおり、Terminal shell in container の条件に proc.tty != 0 があるからです。 -it を付けない kubectl exec は端末を割り当てないので、proc.tty が 0 になり、条件に当たりません。

そして残り 24 本のルールにも当たりません。 id を打っただけでは、機密ファイルも読んでいませんしネットワークにも出ていません。25 本の網は、この操作を 1 度も捉えません。

ステップ2：-it を付けて打つ#

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

$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'id'

実行結果：

uid=10001(appuser) gid=10001(appuser) groups=10001(appuser)

Falco のログ（実測・抜粋）：

13:43:31.320992342: Notice A shell was spawned in a container with an attached terminal |
evt_type=execve user=appuser user_uid=10001 user_loginuid=-1 process=sh
proc_exepath=/bin/busybox parent=containerd-shim command=sh -c id terminal=34816
exe_flags=EXE_LOWER_LAYER container_id=2c1d3c8630bd container_name=backend
container_image_repository=k8s-registry:5000/fanclub-backend container_image_tag=0.4.1
k8s_pod_name=fanclub-backend-56875d65c9-m5q8c k8s_ns_name=fanclub

ステップ3：出力を 1 フィールドずつ読む#

表記の違いに戸惑わないでください。 ルールに書くときはドット区切り（k8s.pod.name / container.image.repository）、アラートに出るときはアンダースコア区切り（k8s_pod_name / container_image_repository）です。 同じフィールドの表記違いにすぎません。 次の演習でルールを書くときはドット区切りを使います。

親プロセスが containerd-shim であるという 1 点が、実務では効きます。アプリケーションが自分で起動したシェルなら、親はアプリケーションのプロセスになります。 親がコンテナランタイムということは、コンテナの外から exec で差し込まれたという意味です。

第16回で扱う監査ログには「誰が kubectl exec を打ったか」が記録されます。 Falco 側には「誰が」は出ません——コンテナの中から見ると、外の人間は見えないからです。2 つを突き合わせて初めて「誰が、何をしたか」が揃います。 これが第18回の DAIR で使う手順になります。

ステップ4：2 つの結果を並べる#

同じことをしているのに、片方だけ記録に残ります。

攻撃者の側から見ると、これは「-it を付けなければ既定ルールには映らない」ということです。 そして攻撃者が対話端末を欲しがるとは限りません——スクリプトから 1 行ずつ実行するほうが、痕跡も残らず自動化もできます。

既定ルールは「運用者が手で入ってきた」を捉えるのに向いています。 それは監査の観点では有用ですが、攻撃の検知としては網が粗いところです。 だからカスタムルールを書きます——次の演習がそれです。

演習②のゴール確認#

カスタムルールはどこに置かれ、いつ反映されるか —— rules.d/ と 2 つの経路#

演習③に入る前に、ルールの置き場所と反映の経路を確認します。ここは世に出回っている手順と本ラボの実機が食い違うところなので、実測に置き換えて読みます。

よく書かれている手順と、本ラボの実機#

どちらの手順も間違いではありません。 ホストに直接 Falco をインストールした構成（systemd で動かす形）では、/etc/falco/falco_rules.local.yaml を編集して systemctl restart falco あるいは kill -1 を送るのが定石です。Helm chart で DaemonSet として動かすと置き場所が変わります。

試験環境の Falco がどちらの構成かは、環境を見て判断します。 falco.org/docs は参照できるので、「どこに置くか」で迷ったら rules_files の設定を実機で確認するのが早い経路です——/etc/falco/falco.yaml の rules_files に列挙されたパスが答えです。

rules_files の読み込み順#

本ラボの実測です。

rules_files:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/falco_rules.local.yaml
  - /etc/falco/rules.d

後から読まれたものが後勝ちです。 rules.d が最後なので、ここに置いたルールが既定を上書きできます。 演習④で使う override は、この順序があって初めて成立します。

既定の falco_rules.yaml を直接編集しないでください。 falcoctl がルールを更新したときに上書きされて消えるからです。編集していい場所は falco_rules.local.yaml と rules.d/ の 2 つだけです。

chart の customRules が置かれる場所#

values.yaml に次のように書くと、rules.d/ の下にキー名のファイルが作られます。

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

Pod の中での実体です（実測）。

/etc/falco/rules.d/rules-fanclub.yaml -> ..data/rules-fanclub.yaml

rules.d/ の中身は ConfigMap のマウントなので、実体は symlink です。 ConfigMap の内容が変わると、kubelet が ..data の指す先を差し替えます。

この差し替えで inotify のイベントが複数回発火するため、ConfigMap を直接更新したときは、Falco のリロードログが 2 回出ます（後述します）。「2 回出ているから壊れている」ではありません。 なお helm upgrade 経由（Pod が作り直される経路）では 1 回だけです。

反映の経路が 2 つある#

同じ「ルールを更新する」でも、経路によってクラスタへの影響が違います。

helm upgrade は DaemonSet を作り直します。 5 台のノードで Falco が順番に落ちて上がるので、その間そのノードは監視されていません。 本ラボでは約 2 分ですが、ノードが多いほど長くなります。

ConfigMap の直接更新は Pod を落としません。 20 秒から 77 秒で反映されます。ただし Helm のリリースとは食い違います——次に helm upgrade を打つと、ConfigMap が values.yaml の内容で上書きされて、直接編集した分は消えます。

本番では「Helm の values を正とし、helm upgrade で配る」が原則です。 直接編集は実験と緊急対応のための手段であり、変更を残すなら values.yaml へ書き戻します。

反映時間は一定しない#

実測（通算 6 回計測）: 20 / 31 / 41 / 51 / 77 / 87 秒。 6 回ともすべて違う値になりました。kubelet が ConfigMap をノードへ同期する周期に当たるタイミング次第なので、一定しません。

本文では「1 分前後・最大 2 分弱」と見込みます。 「◯秒で反映される」と断定すると、30 秒待って「反映されない」と判断して別の手を打つことになります。第14回の denyTTL と同じで、反映を待つ時間を知らないと切り分けができません。

ConfigMap を直接更新したときは、リロードのログが 2 回出る#

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

$ kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco --tail=30 --prefix | grep -E 'Loading rules|schema validation'

実行結果（抜粋）：

Sat Aug 01 13:50:37 2026: Loading rules from:
Sat Aug 01 13:50:37 2026:    /etc/falco/falco_rules.yaml | schema validation: ok
Sat Aug 01 13:50:37 2026:    /etc/falco/rules.d/rules-fanclub.yaml | schema validation: ok
Sat Aug 01 13:50:38 2026: Loading rules from:
Sat Aug 01 13:50:38 2026:    /etc/falco/falco_rules.yaml | schema validation: ok
Sat Aug 01 13:50:38 2026:    /etc/falco/rules.d/rules-fanclub.yaml | schema validation: ok

同じ 3 行が 1 秒差で 2 回出ます。 ConfigMap の symlink 差し替えで inotify イベントが複数発火するためです。壊れているわけでも、ルールが 2 回読まれて重複するわけでもありません。

見るべきは schema validation: ok の側です。 ルールに構文誤りがあると、ここが ok にならず、エラーの内容が続けて出ます。 リロードの回数ではなく、検証結果を読みます。

やってみよう③：カスタムルールを書き、sidecar が漏れることを見つける#

所要時間の目安: 約 12 分（反映待ちを含みます）。list / macro / rule を書き、ConfigMap 経由で配り、検知を確認し、漏れを見つけて直します。試験相当の作業（ルールを書いて反映させて検知させる）なら 6 分です。

ステップ1：ルールを書く#

次の 3 要素をまとめて 1 ファイルに書きます。

- list: fanclub_shell_binaries
  items: [sh, ash, bash, busybox]

- macro: fanclub_backend_container
  condition: (container.image.repository endswith "fanclub-backend")

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

3 要素の役割です。

• list: プロセス名の集合です。sh だけでなく ash / bash / busybox も入れているのは、Alpine では sh の実体が busybox で、呼び方によってプロセス名が変わりえるからです
• macro: 条件の部品です。container.image.repository endswith "fanclub-backend" を名前で呼べるようにしておくと、同じ条件を複数のルールで使い回せます
• rule: 既定のマクロ spawned_process（プロセスが起動した）と container（コンテナ内である）を組み合わせます。 既定ルールが定義しているマクロは、カスタムルールからそのまま呼べます

condition に proc.tty の条件を入れていません。 だからtty の有無にかかわらず検知します——これが既定ルールとの違いです。

% で始まるのがフィールドの参照です。 出力に何を入れるかは自由に決められますが、後で読む人が判断できる情報を入れます。

本ルールでは tty=%proc.tty を入れています。 演習②で「tty があるかどうかで既定ルールの発火が変わる」ことを確認したので、カスタムルールの出力にも tty を出して、対比できるようにしています。

日本語の output もそのまま出力されます（実測）。本番で日本語を使うかは、アラートを受け取る先（第17回の連携先）が扱えるかで決めます。

ステップ2：values.yaml に書いて配る#

ファイル（k8s-ops 上・~/falco-lab/custom-values.yaml）：

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

    - macro: fanclub_backend_container
      condition: (container.image.repository endswith "fanclub-backend")

    - rule: Shell spawned in fanclub-backend
      desc: fanclub-backend コンテナ内でシェルが起動した
      condition: >
        spawned_process
        and container
        and fanclub_backend_container
        and proc.name in (fanclub_shell_binaries)
      output: >
        fanclub-backend でシェル起動 (user=%user.name uid=%user.uid proc=%proc.name
        exe=%proc.exepath cmd=%proc.cmdline tty=%proc.tty
        image=%container.image.repository:%container.image.tag
        pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
      tags: [fanclub, shell, 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

実測値です。

helm upgrade を選ぶと DaemonSet が作り直されます。 5 台が順番に落ちて上がる間、そのノードは監視されていません。 ルールの追加のたびに 2 分の空白を作るのは、本番では避けたいところです。

だからステップ 7 で、Pod を落とさない経路（ConfigMap の直接更新）も試します。 本演習では両方を確認します。

ステップ3：反映を確認する#

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- ls -l /etc/falco/rules.d/

実行結果：

rules-fanclub.yaml -> ..data/rules-fanclub.yaml

ログでも確認します。

実行コマンド（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

ステップ4：tty なしで検知されることを確認する#

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

$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'echo from-backend'

実行結果：

from-backend

Falco のログ（実測）：

16:15:29.316042941: Warning fanclub-backend でシェル起動 (user=<NA> uid=10001 proc=sh
exe=/bin/busybox cmd=sh -c echo from-backend tty=0
image=k8s-registry:5000/fanclub-backend:0.4.1 pod=fanclub-backend-56875d65c9-m5q8c ns=fanclub)

tty=0 と出ています。 演習②で既定ルールが見逃した打ち方が、カスタムルールでは検知されています。

priority も Warning になっています（既定ルールは Notice でした）。自分で書いたルールは、自分で重要度を決められます。

exe=/bin/busybox も出ています。 proc.name は sh ですが、実体は busybox です。 proc.name だけで判定するルールは、別名で呼ばれると外れます——output に proc.exepath を入れておくと、後から実体を確認できます。

ステップ5：同じ Pod の sidecar で試す#

backend Pod の READY は 2/2 です。動き続けているコンテナが 2 つ、起動時だけ動く init コンテナが 1 つという内訳になっています。

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

$ kubectl exec -n fanclub <backend Pod 名> -c log-shipper -- sh -c 'echo from-sidecar'

実行結果：

from-sidecar

Falco のログ：

（1 件も出ません）

同じ Pod の中で、同じ sh を起動しています。それでも片方は検知されません。

原因はルールの macro にあります——container.image.repository endswith "fanclub-backend" で絞っているので、イメージが busybox:1.37 の sidecar は条件に当たりません。

「fanclub-backend を監視するルールを書いた」つもりでしたが、実際に監視しているのは「fanclub-backend というイメージのコンテナ」です。 Pod とコンテナは別物であり、1 つの Pod の中に複数のイメージが同居します。

そして sidecar は攻撃者にとって都合がよい存在です。 busybox には sh も wget も nc も入っており、アプリケーション本体より道具が揃っています。 第12回で「最小イメージにする」を扱いましたが、同じ Pod に busybox の sidecar が居るなら、本体を最小化した効果は薄くなります。

同じ理由で ephemeral container（kubectl debug で差し込むコンテナ）も漏れます——次の節で扱います。

ステップ6：k8s.pod.name で絞る版へ直す#

rules-fanclub.yaml の最終形を全量で示します。image 版のマクロとルールは削除して置き換えます——併存させません。

- 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]

2 本を併存させると、どちらが発火したのか読めなくなります。 前節で見たとおり falco.yaml の rule_matching は first（最初にマッチしたルールで打ち切る）なので、backend コンテナでは先に読まれたほうだけが出ます。 「広げたつもりが、片方しか動いていない」という状態は、本回がずっと扱っている「静かなまま気づかない」そのものです。

絞り込みを直すときは、置き換えます。 足すのではありません。

output に %container.name を足しています。 Pod で絞ると、どのコンテナで起きたかが分からなくなるからです。backend なのか log-shipper なのか、アラートを見た人が判断できるようにします。

絞り方を広げたら、出力に情報を足します。 「検知範囲を広げる」と「アラートが読める」は別の作業です。

実機検証済みです。 k8s.pod.name startswith "fanclub-backend" は backend コンテナと sidecar log-shipper の両方を検知し、fanclub-frontend-… Pod は通算 0 件で巻き込まないことを確認しました（累計ヒット数の差分で測定しています）。

ステップ7：ConfigMap を直接更新して反映させる（Pod を落とさない経路）#

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

$ kubectl get cm -n falco
$ kubectl edit configmap -n falco falco-rules

実測値です。

RESTARTS が増えていないことを確認します。 Pod を落とさずにルールが入れ替わったことが、この 1 列で分かります。

反映は 1 分前後・最大 2 分弱を見込みます。 30 秒待って出ないからといって、別の手を打たないでください。

秒数そのものは覚えなくて構いません。 これは kubelet が ConfigMap をノードへ同期する周期に当たるかどうかで決まる値で、本書ラボの通算 6 回の計測でも 20・31・41・51・77・87 秒とすべて違いました。 覚えるのは「ConfigMap を更新すれば Pod を落とさずに反映される」という性質のほうです。

ステップ8：両方のコンテナで検知されることを確認する#

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

$ kubectl exec -n fanclub <backend Pod 名> -c backend -- sh -c 'echo from-backend'
$ kubectl exec -n fanclub <backend Pod 名> -c log-shipper -- sh -c 'echo from-sidecar'

実行結果（Falco のログ）：

Warning fanclub-backend Pod でシェル起動 (... container=backend image=k8s-registry:5000/fanclub-backend:0.4.1 ...)
Warning fanclub-backend Pod でシェル起動 (... container=log-shipper image=docker.io/library/busybox:1.37 ...)

2 件とも検知されます。 container= の値が違うので、同じ Pod のどちらのコンテナで起きたかが読めます。

演習③のゴール確認#

file_output:
  enabled: true
  filename: /opt/course/xx/alerts

kubectl debug は PSA restricted の namespace で 3 段階に詰まる#

この節は演習ではありません（手を動かすかは読者に任せます）。演習③で見つけた「同じ Pod の別イメージは漏れる」の続きであり、同時に第8回の回収でもあります。

なぜこの節を置くか#

1. 第18回の DAIR で「証拠保全」の手段として ephemeral container を使います。 そのときに詰まらないよう、先に詰まり方を確認しておきます
2. ephemeral container は演習③の image 版ルールから漏れます。 差し込んだコンテナは別イメージなので、イメージで絞ったルールには当たりません——攻撃者が使えば、同じ理由で見えません
3. 第8回で fanclub namespace に PSA enforce: restricted を適用しました。 その制約が運用者自身のデバッグ手段にもそのまま効くことを、実機で確認します

3 段階の詰まり方#

段階 1: 既定のまま打つと Forbidden#

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

$ kubectl debug -n fanclub <backend Pod 名> --image=busybox:1.37 --target=backend -- sh -c 'id'

実行結果（要点）：

Warning: --profile=legacy is deprecated
Error from server (Forbidden): pods "..." is forbidden: violates PodSecurity "restricted:latest":
allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true

kubectl debug の既定プロファイルは legacy で、セキュリティ制約を何も付けません。 第8回で fanclub namespace に enforce: restricted を付けたので、そのままでは admission で弾かれます。

違反は 3 点です——allowPrivilegeEscalation != false / unrestricted capabilities / runAsNonRoot != true。restricted プロファイルの要件を、kubectl debug が 1 つも満たしていません。

--profile=legacy is deprecated の警告も出ます。 既定が非推奨のまま残っているので、「既定で打つ」こと自体が推奨されていません。

段階 2: --profile=restricted を足すと今度はイメージ側で詰まる#

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

$ kubectl debug -n fanclub <backend Pod 名> --image=busybox:1.37 --target=backend --profile=restricted -- sh -c 'id'

実行結果（要点）：

CreateContainerConfigError
container has runAsNonRoot and image will run as root

admission は通りましたが、kubelet がコンテナを起動できません。

--profile=restricted は runAsNonRoot: true を付けますが、runAsUser は付けません。 一方 busybox:1.37 は Dockerfile に USER の指定が無く、root で動きます。 「root で動くな」と指示されたのに「誰で動け」が指定されていないので、kubelet は判断できずに失敗します。

これは第8回で扱った restricted の要件そのものです。 runAsNonRoot: true を満たすには、イメージ側に非 root の USER があるか、Pod 側に runAsUser があるかのどちらかが要ります。プロファイルは前者を仮定しています。

拒否される場所が 2 段階に分かれていることも重要です——1 段階目は API サーバの admission、2 段階目はノードの kubeletです。第14回の ImagePolicyWebhook も admission でしたが、admission を通ったからといって起動するとは限りません。

段階 3: --custom で runAsUser を渡すと起動する#

ファイル（k8s-ops 上・~/falco-lab/debug-profile.json）：

{
  "securityContext": {
    "runAsUser": 10001,
    "runAsNonRoot": true,
    "allowPrivilegeEscalation": false,
    "capabilities": { "drop": ["ALL"] },
    "seccompProfile": { "type": "RuntimeDefault" }
  }
}

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

$ kubectl debug -n fanclub <backend Pod 名> --image=busybox:1.37 --target=backend --profile=restricted --custom=/home/developer/falco-lab/debug-profile.json -- sh -c 'id'

実行結果：

uid=10001 gid=0(root)

--custom には絶対パスを渡しています。 bash のチルダ展開は --custom=~/… の形では働かないことがあるためで、ここで詰まると原因が分かりにくくなります。

runAsUser: 10001 を指定して起動しました。 第6回・第8回で backend に設定した uid と同じ値です。同じ uid にすることで、対象コンテナのファイルにアクセスできる可能性が上がります——ただし次のとおり、それでも限界があります。

JSON の 5 項目は restricted プロファイルの要件そのものです。--profile=restricted が付ける分と重複していますが、--custom は上書きなので、必要な項目は明示的に並べます。

--target を付けても /proc/1/root/ は読めない#

実行コマンド（起動した ephemeral container の中）：

$ ls /proc/1/root/

実行結果：

ls: /proc/1/root/: Permission denied

--target=backend を付けると PID 名前空間を共有するので、対象コンテナのプロセスが /proc に見えます。 それでも /proc/1/root/ は読めません。

理由は uid です。 ephemeral container は runAsUser: 10001 で動いていますが、/proc/1/root は root 所有なので、10001 では辿れません。

「PID 名前空間を共有すれば対象コンテナのファイルが見える」は成り立ちません。 見えるのはプロセスの一覧までで、ファイルシステムを辿るには権限が要ります。

restricted の制約を守りながら調べられる範囲は、思ったより狭いところです。 第18回の証拠保全では、この制約を前提に手段を選びます——kubectl cp・ログ・Falco のアラートそのものが、実質の証拠になります。

失敗した ephemeral container は削除できない#

実測では、失敗した ephemeral container は CreateContainerConfigError のまま Pod に残り、削除できませんでした。

ephemeral container は追加専用です。 1 度差し込んだら、Pod を作り直すまで消えません。

段階 1 と段階 2 で失敗した分が、そのまま Pod にぶら下がります。 kubectl get pod -o yaml の ephemeralContainers に残り、kubectl describe にもエラーのまま出続けます。

やり直すときは、別の Pod で試すか、Pod を作り直します。 本番の Pod で試行錯誤すると、そのオブジェクトが「エラーを抱えた Pod」として監視に映り続けます——調査のつもりが、別のアラートの原因になります。

プロファイルは打つ前に決めます。 --profile=restricted --custom=<file> の形をあらかじめ用意しておくのが実務の作法です。

ephemeral container は image で絞ったルールから漏れる#

ephemeral container のイメージは busybox:1.37 です。 演習③のステップ 1〜4 で書いた image で絞るルールには当たりません。sidecar が漏れたのとまったく同じ理由です。

ステップ 6 で k8s.pod.name 版へ直した後なら、ephemeral container も検知範囲に入ります——実測で確認できます。

実行結果（pod 版のルールが入った状態で kubectl debug を打ったときの Falco のログ・実測）：

21:37:54.414180479: Warning fanclub-backend Pod でシェル起動 (user=<NA> uid=10001 proc=sh
exe=/bin/sh cmd=sh -c echo eph-check tty=0 container=debugger-4bhjz
image=docker.io/library/busybox:1.37 pod=fanclub-backend-56875d65c9-6cdm7 ns=fanclub)

container=debugger-4bhjz / image=docker.io/library/busybox:1.37 と出ています。 差し込んだコンテナの名前とイメージがそのまま記録に残ります——Pod で絞っておけば、後から差し込まれたものも同じ網に入るということです。

これは攻撃側から見ると分かりやすい抜け道です。 kubectl debug を打てる権限があれば、監視対象のイメージ以外のコンテナを、監視対象の Pod の中に差し込めます。 第4回で RBAC を絞ったのは、こういう操作を打てる主体を減らすためでもあります。

そして「誰が kubectl debug を打ったか」は Falco には出ません——第16回の監査ログの担当です（pods/ephemeralcontainers への操作として記録されます）。

3 段階のまとめ#

やってみよう④：誤検知を再現してから潰す#

所要時間の目安: 約 12 分（override の反映 31 秒と、ConfigMap の削除 → helm upgrade による書き戻しを含みます。書き戻しではローリング再起動は起きません）。誤検知を意図的に発生させ、override で潰し、他の検知が生き残っていることを 3 通りで確認します。 試験相当の作業（例外マクロを override して反映させる）なら 4 分です。

誤検知は「待つ」のではなく「起こす」#

誤検知のチューニングを演習にするとき、いちばんやりがちな失敗は「発火するのを待つ」ことです。

待って測ると、次のことが起きます——①適用前の 3 分間がもともと 0 件だった ②override を適用した ③適用後の 3 分間も 0 件だった。 これでは「効いた」証明になりません。 もともと 0 件だったものが 0 件のままなだけです。

第13回・第14回で繰り返してきた「測りたいものを測る」の 3 例目です。 本演習は「発火させてから測る」に切り替えます。

題材選びで 2 回失敗しました#

「発火させてから測る」に切り替えても、まだ足りませんでした。 本書ラボに実在する誤検知を 2 つ調べましたが、どちらも演習には使えませんでした。 使えなかった理由のほうが、Falco の理解に効きます。

fluent-bit のほうは、一度は「Pod を消せば必ず出る」ように見えました。 実際、最初の観察では 0 件 → Pod 削除 → 1 件と再現しました。ところが日を改めて同じ手順を踏むと、1 件も出ませんでした。

理由は、ルールの定義を読めば分かります。

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- grep -A 2 'macro: k8s_api_server' /etc/falco/falco_rules.yaml

実行結果：

- macro: k8s_api_server
  condition: (fd.sip.name="kubernetes.default.svc.cluster.local")

fd.sip.name は「接続先 IP の逆引き名」です。 つまりこのルールは、Falco が 10.96.0.1 を kubernetes.default.svc.cluster.local という名前として解決できたときにだけ発火します。

接続そのものは毎回起きています。 起きていないのは名前の解決のほうで、これはノードによっても、タイミングによっても変わります。 本書ラボでは Control Plane では解決できることがあり、Workload ノードでは通算 0 件でした。

そこで、本演習は読者が確実に再現できる題材に変えます——演習②で自分の手で発生させた Terminal shell in container です。

これは誤検知として理想的な題材です。 運用者が調査のために kubectl exec -it を打つたびにアラートが出る——攻撃とは何の関係もない、日常の運用操作が検知されるという、いちばんありふれた形だからです。

チューニング用の「空マクロ」という仕組み#

既定ルールの多くは and not user_◯◯_conditions（または user_known_◯◯_activities）という条件を持ち、そのマクロの既定値は (never_true) になっています。

既定は (never_true) なので、常に偽です。 つまり and not (never_true) は and true と同じで、何も除外していません。

ここを自分の環境に合わせた条件で置き換えることで、除外リストを作ります。 既定ルールの condition を直接書き換えないでください——falcoctl がルールを更新したときに消えますし、元のルールが何を検知していたかが分からなくなります。

replace は既定の条件を捨てる、append は足す#

override には replace と append の 2 つがあります。 違いは既定の条件を残すかどうかです。

本回で置き換える 2 つのマクロは既定が (never_true) なので、どちらでも同じ結果になります。 それでも replace を選ぶのは、「置き換えるつもりで書いている」と読み手に伝えるためです。

Redirect STDOUT/STDIN to Network Connection in Container の desc には、ルール自身が「このルールはノイズを出す。user_known_stand_streams_redirect_activities テンプレートマクロで調整できる」と書いてあります（実測）。ルールの作者が、チューニングされる前提で書いています。

「例外を書く場所があらかじめ用意されている」というのが Falco の設計です。 チューニングは想定された使い方であり、ルールをコピーして書き換えるのは最後の手段です。

ステップ1：baseline を測る#

件数は「直近◯分」ではなく通算で数えます。 --since で窓を切ると、直前の操作で出たアラートが窓に入り込み、増分を読み違えます（この誤りは本書の検証でも起きました）。操作の前後で通算を数えて、その差を見ます。

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

$ kubectl logs -n falco <k8s-wl-01 上の falco Pod 名> -c falco | grep -c 'attached terminal'

実行結果（実測）：

0

この数を控えておきます。 Pod を作り直していれば 0 ですが、演習②で -it を打っていれば 1 以上になっています。0 でなくても構いません——見るのは差だからです。

ステップ2：誤検知を起こす#

運用者が調査のために入る、という想定です。 3 回打ちます。

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

$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo run-1'
$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo run-2'
$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo run-3'

ステップ3：数える#

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

$ kubectl logs -n falco <k8s-wl-01 上の falco Pod 名> -c falco | grep -c 'attached terminal'

実行結果（実測）：

3

3 回打って 3 件です。 打った回数と検知の件数が一致します——これが「起こしてから測る」の意味です。読者の環境でも、何度でも同じように再現します。

ルールが間違っているわけではありません。 「コンテナ内で対話端末付きのシェルが起動した」は侵入後の挙動としてよくある形であり、検知する価値があります。問題は、正規の運用操作と区別がついていないことです。

ステップ4：override で潰す#

追記するのはこの 4 行です。

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

足した後の 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

マクロの条件は、演習③で書いた fanclub_backend_pod とまったく同じ形です。 「自分たちが監視対象として定義した範囲では、対話端末付きのシェルは想定内である」という意味になります。

ここで fanclub_backend_pod マクロを参照しないのは、除外の条件と検知の条件を独立させておくためです。片方を広げたときに、もう片方まで一緒に動いてしまうのを防ぎます。

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

$ kubectl edit configmap -n falco falco-rules

反映は 31 秒でした（実測）。schema validation: ok が出ることを必ず確認します。

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

$ kubectl logs -n falco <k8s-wl-01 上の falco Pod 名> -c falco --tail=12 | grep -E 'Loading rules|schema validation'

実行結果（実測）：

Sat Aug 01 16:28:34 2026: Loading rules from:
Sat Aug 01 16:28:34 2026:    /etc/falco/falco_rules.yaml | schema validation: ok
Sat Aug 01 16:28:34 2026:    /etc/falco/rules.d/rules-fanclub.yaml | schema validation: ok

override の記法を誤ると、ルール全体が読み込まれず、それまで動いていたカスタムルールごと止まります。 「1 行足しただけ」でも、読み込み結果を確認してから次へ進みます。

ステップ5：3 通りで確認する#

チューニングの後に確認すべきことは「静かになったこと」ではありません。 必要な検知が残っていることです。3 通りで確かめます。

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

$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo after-1'
$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo after-2'
$ kubectl exec -it -n fanclub <backend Pod 名> -c backend -- sh -c 'echo after-3'
$ kubectl exec -it -n fanclub <frontend Pod 名> -c frontend -- sh -c 'echo frontend-it'

実行結果（通算の増分・実測）：

3 行目が重要です。 override はルールを無効にしたのではなく、条件を狭めただけです。同じ namespace の別の Pod では、既定ルールは今までどおり発火します。

もし 3 行目が 0 だったら、絞りすぎです。 「静かになった」ことを成功と読むと、この違いが見えません。

ステップ6：values.yaml へ書き戻す（この演習を「残す」ための必須手順）#

ここまでの 2 回の変更（演習③の pod 版ルール・演習④の override）は、すべて ConfigMap を直接編集して入れたものです。 それは実験と緊急対応のための手段でした。残すなら values.yaml が正でなければなりません。

~/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

ここで素直に helm upgrade を打つと、失敗します。 失敗の仕方に本回で最も重要な論点があるので、次の節で扱います。

直接編集したものは、そのままでは Helm に戻せません#

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

$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml

実行結果（実測）：

Error: UPGRADE FAILED: conflict occurred while applying object falco/falco-rules /v1, Kind=ConfigMap: Apply failed with 1 conflict: conflict with "kubectl-client-side-apply" using v1: .data.rules-fanclub.yaml

原因は、Kubernetes がフィールドごとに「誰が書いたか」を覚えているためです。 kubectl で直接編集した時点で、.data.rules-fanclub.yaml の所有者が kubectl-client-side-apply になりました。Helm は Server-Side Apply で書こうとしますが、そのフィールドは自分のものではないので拒否されます。

Server-Side Apply は、kubectl 側ではなく API サーバ側でマージを行う方式です。 どのフィールドを誰（field manager）が書いたかをオブジェクトに記録するところが、従来のクライアント側 apply と違います。その記録が metadata.managedFields です——次のコマンドで実際に見えます。

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

$ kubectl get cm falco-rules -n falco -o jsonpath='{range .metadata.managedFields[*]}manager={.manager} op={.operation}{"\n"}{end}'

実行結果（実測）：

manager=helm op=Apply
manager=kubectl-client-side-apply op=Update

管理者が 2 人いる状態です。 これが衝突の正体です。

$ kubectl get ds falco -n falco -o jsonpath='{.metadata.generation}'
3

$ kubectl rollout history ds/falco -n falco
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

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

$ helm history falco -n falco

実行結果（実測・抜粋）：

REVISION	STATUS    	DESCRIPTION
2       	deployed  	Upgrade complete
3       	failed    	Upgrade "falco" failed: conflict occurred while applying object falco/falco-rules

deployed はまだ REVISION 2 のままです。 つまり ConfigMap は直接編集した内容のままで、Helm の管理下には戻っていません。

解決は、ConfigMap をいったん削除してから helm upgrade を打つことです。

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

$ kubectl delete cm falco-rules -n falco
$ helm upgrade falco oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0 --namespace falco -f ~/falco-lab/custom-values.yaml
$ helm list -n falco

実行結果（実測・抜粋）：

Release "falco" has been upgraded. Happy Helming!
REVISION: 4
STATUS: deployed

helm list -n falco の側はこう見えます（実測）。

NAME    NAMESPACE  REVISION  UPDATED                                  STATUS    CHART        APP VERSION
falco   falco      4         2026-08-02 01:32:34.322339738 +0900 JST   deployed  falco-9.1.0  0.44.1

upgrade 自体は 1 秒で終わりました（実測）。ConfigMap の中身が values.yaml と同じなので、DaemonSet のチェックサムが変わらず、ローリング再起動も起きません。

所有者が戻ったことを確認します。

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

$ kubectl get cm falco-rules -n falco -o jsonpath='{range .metadata.managedFields[*]}manager={.manager}{"\n"}{end}'

実行結果（実測）：

manager=helm

ConfigMap を直接編集した状態のままにすると、次に誰かが helm upgrade falco を打った瞬間、本回の成果が黙って消えます——今回のように失敗して止まってくれるとは限りません。ルールが減っても Falco はエラーを出しません。アラートが出なくなるだけです。 そしてアラートが出ないのは、平常時と見分けがつきません。

本回はこれを 3 回見てきました。 ①1 台だけ Falco が上がっていなくても静か ②tty を付けなければ既定ルールに映らない ③image で絞ると sidecar が映らない。「values.yaml へ書き戻さない」は、4 つ目の同じ失敗です。

第16回以降はこのルールが入っている前提で進みます。 残す判断をしたなら、残る形にするまでが作業です——演習①の sysctl 永続化とまったく同じ話です。

ステップ7：差し込んだデバッグコンテナを片付ける#

ephemeral container は削除できません。 前の節で kubectl debug を試した Pod には、失敗したまま残っているコンテナがあります。

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

$ kubectl get pod -n fanclub <backend Pod 名> -o jsonpath='{range .status.ephemeralContainerStatuses[*]}{.name}={.state}{"\n"}{end}'

実行結果（実測・抜粋）：

debugger-fl55t={"waiting":{"message":"container has runAsNonRoot and image will run as root ...","reason":"CreateContainerConfigError"}}

この Pod を describe するたび、以降ずっとこのエラーが目に入ります。 片付ける唯一の方法は Pod を作り直すことです。

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

$ kubectl delete pod -n fanclub <ephemeral container が残っている backend Pod 名>

Deployment が新しい Pod を作り直し、ephemeral container の記録も一緒に消えます。 この Pod は Deployment 配下なので削除すれば作り直されます——Deployment / StatefulSet の配下でない Pod を同じ手で消すと、戻りません。 調査のために差し込んだものを、調査が終わったら片付ける——第18回のインシデント対応でも同じ作法が要ります。

演習④のゴール確認#

監視する側は何に守られているか —— Falco 自身が spc_t である#

検知基盤そのものの権限を確認して、実装の話を締めます。

Falco は特権コンテナである#

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

$ kubectl exec -n falco <falco Pod 名> -c falco -- cat /proc/self/attr/current

実行結果：

system_u:system_r:spc_t:s0

第6回で containerd の enable_selinux = true にして、コンテナが container_t:s0:cN,cM になることを確認しました。 それでも Falco は spc_t（super privileged container）です。

理由は privileged: true だからです。 特権コンテナは type enforcement の対象外になります。第6回でやったハードニングは、Falco には効いていません。

これは不具合ではありません。 Falco はカーネルの syscall ストリームを読む必要があり、SELinux で拘束されると仕事ができません。 監視の道具は、監視対象より強い権限を持たないと監視できません。

衝突は起きない（第10回・第11回との違い）#

第10回と第11回では、第6回の SELinux が原因で新しいツールが動きませんでした。 本回は衝突しません。 ただし衝突しない理由が「特権だから」です——制約を回避しているだけであり、安全だから衝突しないのではありません。

falco namespace に PSA ラベルは付いていない#

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

$ kubectl get ns falco --show-labels

実行結果（実測）：

NAME    STATUS   AGE     LABELS
falco   Active   4h51m   kubernetes.io/metadata.name=falco,name=falco

第8回で fanclub に enforce: restricted を付けましたが、falco には付けていません。 付けると privileged: true の Pod が admission で弾かれて Falco が動きません。

PSA を全 namespace に一律で適用できないのは、このように正当な理由で特権が要るワークロードがあるからです。 第8回で扱った「まず PSS、足りない制約だけ Gatekeeper / CEL」という順序の中で、「例外を作る namespace を決める」ことも設計の一部です。

例外を作ったら、その namespace に何を置けるかを RBAC で絞ります。 falco namespace に Pod を作れる人は、実質的にノードへの特権アクセスを持ちます——第4回の RBAC 監査の対象になります。

検知基盤の権限#

暗記必須コマンドと、ラボ固有の事情の切り分け#

試験中に参照できるものと、できないもの#

CKS の試験中に参照できるのは 8 件だけで、うち 3 件はサブパス限定です。

第12回（Kubesec / KubeLinter）・第13回（Trivy）・第14回（Cosign）は、いずれも参照不可の道具でした。 3 回続けて「引けないから覚える」を書いてきました。

本回は逆です。 falco.org/docs は 8 件のうちの 1 つで、ルールの記法もフィールド名も引けます。

それでも覚えておく価値があるものは残ります——①引く時間を減らすためのフィールド名 ②kubectl 側の打ち方（Falco のドキュメントには載っていません）③Helm のコマンド（helm.sh/docs は引けません）の 3 つです。

暗記必須コマンド#

kubectl logs -n <ns> -l <label> -c falco
kubectl exec -it -n <ns> <pod> -- sh

- list: <名前>
  items: [...]

- macro: <名前>
  condition: (...)

- rule: <名前>
  desc: ...
  condition: (spawned_process and container and ...)
  output: "... (%proc.cmdline %container.name %k8s.pod.name)"
  priority: WARNING
  tags: [...]

alias k=kubectl について#

CKS の SSH ホストには alias k=kubectl と bash 補完が設定済みです。本文では読みやすさのために kubectl と全綴りで書いていますが、試験ではエイリアスを使ってください。 加えて export do="--dry-run=client -o yaml" を開始直後に設定しておくと、マニフェストの雛形生成が速くなります。

本回はマニフェストを書く場面が少ない（ルールは YAML ですが Kubernetes のオブジェクトではありません）ので、do の出番は限られます。それでも kubectl logs / kubectl exec は何度も打つので、エイリアスの効果は大きいところです。

「入れない判断・外す判断・残す判断」の系譜#

本巻はここまで、入れないと決めたものと入れて外したものを積み上げてきました。

残す判断をするのは本回が初めてです。 理由は第17回と第18回が土台にするからであり、残すために sysctl の永続化まで作業しました。

「入れる / 入れない」だけでなく「入れたものを維持できるか」まで含めて判断します——これが本巻が繰り返してきた設計の話です。

第16回への 1 行#

本回で コンテナの中で起きたことを syscall のレベルで捉えました。 アラートには「何が起きたか」は出ますが、「誰がやったか」は出ません。 kubectl exec を打った人間は、コンテナの中からは見えないからです。第16回では、Kubernetes API 側の記録を扱います。

まとめ#

• Falco は syscall を見ます。 プロセスの起動・ファイルのオープン・ネットワーク接続を捉えます。Kubernetes API に対する操作は見ていません——それは第16回の監査ログの担当です
• ドライバは auto で modern_ebpf が選ばれました。 /sys/kernel/btf/vmlinux があるので CO-RE が成立し、download.falco.org へのアクセスは 1 度も発生しません（No artifacts needed for the selected driver.）。当初想定していた whitelist の追加は不要でした
• helm repo add falcosecurity ... は Forbidden で通りません。 OCI（oci://ghcr.io/falcosecurity/charts/falco --version 9.1.0）なら通ります。 第13回・第14回に続き、whitelist は 44 行のままです
• 依存 3 chart（falcosidekick 0.12.1 / k8s-metacollector 0.1.10 / falco-talon 0.3.0）は OCI アーティファクトに同梱されています。 Chart.lock が到達できない URL を指していても install は成立します。設定に書いてある URL が必ず使われるとは限りません
• helm install が成功しても、5 台中 4 台しか起動しないことがあります。 Error: could not initialize inotify handler。上限 fs.inotify.max_user_instances = 128 に対し、k8s-wl-01 は 144 使っていました（cp-01 は 67 / wl-02 は 96）。containerd-shim が 1 プロセスあたり 2〜4 インスタンス使い、効くのはプロセスの個数（= ノードの Pod 密度）なので、Pod が多いノードから先に枯渇します
• sysctl -w fs.inotify.max_user_instances=512 で直り、Pod 削除から 45〜61 秒で Running になりました。 sysctl -w はノード再起動で戻るので、/etc/sysctl.d/ へ永続化します——本回の Falco を残す判断には、残せる状態にする作業が伴います
• max_user_watches は 60,255 で余裕があります。 枯渇しているのは instances のほうです。名前が似ているので取り違えないでください
• falcoctl が ghcr.io からルールとプラグインを取り、cosign で署名を検証しています（Verifying signature for artifact → Signature successfully verified!）。第14回で手で打った検証が、道具の内部で自動的に走っています
• falcoctl の index（falcosecurity.github.io/falcoctl/index.yaml）には到達できませんが、artifact の取得先が ghcr.io なので install は成功します
• k8s_pod_name / k8s_ns_name は container プラグイン 0.7.1 が付けています。 k8s-metacollector は不要です
• 既定ルールは 25 本しかありません。 攻撃の流れ（入る → 調べる → 外へ出す → 消す → 上がる）に沿って並んでいます。「Falco を入れれば検知される」ではなく「25 本の網が張られる。足りない分は自分で書く」が正しい理解です
• rule_matching は first（最初にマッチしたルールで打ち切る）、priority の出力しきい値は debug（全優先度を出す）、rules_files は falco_rules.yaml → falco_rules.local.yaml → rules.d の順です
• 素の kubectl exec は既定ルールに引っかかりません。 Terminal shell in container には proc.tty != 0 があり、-it を付けないと発火しません（実測: terminal=34816）。「記事どおりに打ったのに何も出ない」の正体はここにあります
• 絞り込みは、常に「見なくなるもの」を作ります。 既定ルールが tty で絞っているのは誤検知を減らすためですが、tty を使わない操作は 1 件も映りません
• chart の customRules は /etc/falco/rules.d/<キー名> に置かれます。 falco_rules.local.yaml ではありません。実体は ConfigMap の symlink です
• 反映の経路が 2 つあります。 helm upgrade は DaemonSet をローリング再起動します（5 台で約 2 分・その間そのノードは監視されません）。ConfigMap の直接更新は Pod を落とさず自動リロードされました（通算 6 回の計測で 20 / 31 / 41 / 51 / 77 / 87 秒——すべて違いました。「1 分前後・最大 2 分弱」と見込みます）
• ConfigMap を直接更新したときは、リロードのログが 2 回出ます（helm upgrade 経由では 1 回です）。ConfigMap の symlink 差し替えで inotify イベントが複数発火するためで、壊れているのではありません。 見るべきは schema validation: ok の側です
• カスタムルールは tty が無くても検知します（実測: tty=0 / exe=/bin/busybox）。proc.name は sh でも実体は busybox なので、output に proc.exepath を入れておきます
• container.image.repository で絞ったルールは、同じ Pod の sidecar を見逃します。 backend Pod には log-shipper（busybox:1.37・native sidecar）が同居しており、そちらで sh を起動しても検知されませんでした。 k8s.pod.name で絞る版に直すと両方が検知されます
• sidecar は攻撃者にとって都合がよい存在です。 busybox には sh も wget も nc も入っています。第12回で本体を最小化しても、同じ Pod に busybox が居れば効果は薄くなります
• kubectl debug は PSA restricted の namespace で 3 段階に詰まります。 ①既定（legacy）は admission で Forbidden（3 点の PSA 違反）②--profile=restricted は kubelet で CreateContainerConfigError（runAsNonRoot はあるが runAsUser が無く busybox は root で動く）③--custom で runAsUser: 10001 を渡して起動（uid=10001 gid=0(root)）
• --target で PID 名前空間を共有しても /proc/1/root/ は Permission denied です。 見えるのはプロセスの一覧までで、ファイルを辿るには権限が要ります
• 失敗した ephemeral container は削除できません。 Pod を作り直すまで残ります。プロファイルは打つ前に決めておきます
• ephemeral container は image で絞ったルールから漏れます——sidecar と同じ理由です
• 誤検知は「待つ」のではなく「起こしてから測る」。 通算 0 件 → kubectl exec -it を 3 回 → +3 件（100% 再現します）→ override 適用（反映 31 秒）→ もう一度 3 回打って +0 件 → 同時に自分のカスタムルールは +3 件（生存） → frontend Pod では +1 件（絞った範囲の外では既定ルールが生きています）
• 「変更前 0 件 → 変更後 0 件」では何も言えません。 効果を測るときは、変更前に必ず 1 以上を出しておきます。第13回・第14回に続く「測りたいものを測る」の 3 例目です
• 既定ルールにはチューニング用の空マクロ（既定 (never_true)）が用意されています。 and not user_known_◯◯_activities（あるいは user_expected_◯◯_conditions）を override: condition: replace で置き換えます。接頭辞は 2 通りあるので、探すときは grep -E 'user_known|user_expected' です。既定ルールを直接書き換えません
• チューニングの後は「静かになったこと」ではなく「必要な検知が残っていること」を確認します
• 本ラボに実在した誤検知は 2 つとも演習に使えませんでした。 longhorn-manager 側は wl-01 のみ 20 分で 6 件と間欠的で、Contact K8S API Server From Container 側は fd.sip.name（接続先の逆引き名）に依存するのでノードとタイミングで出たり出なかったりしました。演習には、読者が確実に再現できる操作（kubectl exec -it）を題材に選びました
• Falco 自身は spc_t です（privileged: true）。第6回の SELinux 拘束の外にいます。 第10回の gVisor・第11回の SPIRE のような衝突は起きませんが、衝突しない理由は「特権だから」です
• falco namespace に PSA ラベルは付いていません。 付けると privileged が通りません。例外を作る namespace は、RBAC で誰が書けるかを絞ります
• 検知基盤の負荷は CPU 4〜14m / メモリ 106〜154Mi・syscall drop 0 件です。 drop が出ると、その分アラートが出ません——「静かだから安全」の 3 つ目の原因になります
• ConfigMap を直接編集したものは、そのままでは helm upgrade で戻せません。 フィールドの所有者が kubectl-client-side-apply になり、Helm の Server-Side Apply が conflict で拒否されます。しかも kubectl rollout status は successfully rolled out を返すので失敗が表に出ません（DaemonSet には触れていないため当然です）。成否は helm list か helm history で見ます。 解決は ConfigMap をいったん削除してから helm upgrade（実測 1 秒・REVISION 4 deployed・manager が helm 単独へ戻る）
• 本回で入れた Falco は残します。 第10回の gVisor・第14回の ImagePolicyWebhook は撤去しましたが、本回は第17回・第18回が土台にします
• 本回の軸: 検知の仕組みは、検知しなかったときに何も言いません。 「アラートが出ていない」には何も起きていないと見ていないの 2 つの意味があります。本回は 4 回、その区別を実機で作りました——①1 台だけ起動していない ②tty が無いと既定ルールに映らない ③image で絞ると sidecar が映らない ④helm upgrade が失敗しても rollout status は成功と言う
• 本回も whitelist を 1 行も足していません（44 行のまま・3 回連続です）

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

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

1. Falco は syscall を監視するため、kubectl get secret のような Kubernetes API に対する操作も検知できる
2. modern_ebpf ドライバは、カーネルに合わせた probe を外部からダウンロードする必要がない
3. helm install が成功していれば、DaemonSet の Pod は全ノードで起動していると考えてよい
4. Falco の既定ルール Terminal shell in container は、kubectl exec に -it を付けなくても発火する
5. Helm chart の customRules に書いたルールは /etc/falco/falco_rules.local.yaml に配置される
6. watch_config_files が有効な構成では、ルールの ConfigMap を更新すれば Pod を再起動しなくても反映される
7. container.image.repository で対象を絞ったルールは、同じ Pod 内で別のイメージが動いているコンテナも検知する
8. 既定ルールの誤検知を消すときは、falco_rules.yaml の該当ルールの condition を直接書き換えるのが正しい
9. privileged: true で動く Falco のコンテナは、containerd の enable_selinux を有効にしていても container_t ではなく spc_t になる

次回予告#

第16回「監査ログ設計・分析 + 攻撃フェーズ特定」では、Kubernetes API 側の記録を扱います。

本回のアラートには user=appuser（コンテナ内のユーザー）と parent=containerd-shim（外から差し込まれたこと）までは出ましたが、kubectl exec を打った人間の名前は 1 度も出ませんでした。 コンテナの中から、外の人間は見えないからです。

第16回は、その見えなかった側を埋めます。 Audit Policy を設計して kube-apiserver に適用し、誰が・いつ・何に対して・どの操作を打ったかを記録します。そして第2回で保留した kube-bench の FAIL（1.2.16〜1.2.19）が、3 点セットを入れれば PASS へ転じることも確認します。

Falco（syscall）と監査ログ（API 操作）の 2 つが揃うと、「何が起きたか」と「誰がやったか」が結びつきます。 ただし第16回では、その監査ログを回の終わりに撤去します——平文の危険と容量という代償を実測したうえでの判断です。第18回のインシデント対応は、その代償が実害に変わるところから始まります。

→ 詳しくは第16回 監査ログ設計・分析 + 攻撃フェーズ特定

リンク