ノードOS堅牢化とfirewalld【CKS第7回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第7回です。第6回ではコンテナが使えるシステムコール・権限・ラベルを絞りました。本回はその 1 段下、コンテナが載っているノード OS そのものを削ります。

本回の主題は 1 文で書けます。動いているものを減らし、権限を絞り、外に出る経路を狭める——ノード OS を 3 方向から削ります。

第6回は「カーネルが何を止めるか」でした。本回は「そもそも何を動かさないか」です。この 2 回で CKS の D3（System Hardening）が完結します。 実機作業は k8s-wl-02 の 1 台に限定し、Control Plane Node では読み取りしか行いません。

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

本回も CKS ドメイン D3: System Hardening（配点 10%） です。D3 は 4 つのコンピテンシーからなり、第6回が担当したのは 4 番目の 1 つだけでした。残る 3 つを本回で埋めます。

第6回と本回の 2 回で D3 が完結します。 配点は 10% ですが、ここで扱う判断（何を止めてよく、何を止めると壊れるか）は、後半の第15回以降でランタイム検知やインシデント対応を扱うときの土台にもなります。

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

本回の起点#

起点は第6回の完了状態です。第2巻から引き継いだ 9 VM 構成（Control Plane Node 3 台 + Workload Node 2 台 + 作業端末・レジストリ・LB・プロキシ）が稼働している前提で進めます。ラボの Kubernetes が v1.36.3 なのは、第5回のパッチアップグレード演習を通した後の状態だからです。

演習の進め方#

この回のゴール#

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

• 稼働サービスを running と enabled の両方で棚卸しし、止めてよいもの・止めてはいけないものを根拠つきで仕分けられる
• disable と mask の違いを説明し、依存関係経由の起動まで止められる
• ss の bind アドレスと firewalld の許可を突き合わせ、「listen していないのに開いている穴」を見つけられる
• firewalld のゾーンモデル（同じポートでも来る経路で結果が変わる）と、iptables-nft との同居を説明できる
• 環境変数のプロキシに強制力が無いことを実機で確かめ、firewalld の policy object で egress を強制できる
• 閉じすぎるとクラスタのどこが落ちるか（まず DNS、次にノード間の通信）を、実際に壊して復旧した経験として説明できる。あわせて「IP 直指定のテストでは、壊れたことに気づけない」という確認手順の落とし穴を説明できる
• 棚卸しは「余分な穴」だけでなく「足りない許可」も見つけることを、実例（構築時から塞がっていた通信）で説明できる

なぜホスト OS を削るのか（コンテナの「下」にある層）#

第6回ではコンテナの中を締めました。syscall を seccomp で絞り、capabilities を drop し、SELinux のラベルでファイルアクセスを拘束しました。しかし、コンテナが破られた後に攻撃者が次に触るのはノード OS そのものです。ノードには sshd が待ち受け、sudo があり、外へ出ていく経路があります。コンテナの中をどれだけ締めても、その下の層が緩ければ足場として使われます。

本回は 3 方向で削ります。最初に地図を渡します。

3 方向に共通する原則は 1 つです。動いていないものは攻撃されません。 脆弱性が公表されても、そのサービスを止めていれば影響を受けません。パッチ適用より確実で、コストも低い。これが footprint reduction（攻撃面の縮小）という考え方の核です。

稼働サービスの棚卸し — running と enabled の両輪#

「動かすものを減らす」の本体です。まずノードで何が動いているかを数えます。

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

$ LC_ALL=C systemctl list-units --type=service --state=running --no-pager --no-legend

本書ラボの k8s-wl-02 では 22 本が返りました。全量を並べても読み通せないので、判断の型を表にします。1 本ずつ「これは何のために動いているか」「止めると誰が困るか」を言葉にできる状態を目指してください。

ここで SIEM という語を使いました。ログを集約して相関分析するセキュリティ監視基盤のことで、第16回と第17回で扱います。rsyslog は journald と役割が重なって見えますが、外部の SIEM へログを転送する経路がここに設定されていることが多いので、止める前に /etc/rsyslog.conf と /etc/rsyslog.d/ の転送設定を確認してください。

hypervkvpd / hypervvssd は Hyper-V 上の仮想マシンにだけ現れます。棚卸しで最初にやるべきなのは、こうした「自環境固有のもの」を見分けることです。手元の一覧に本書と違うサービスが出ていたら、それは環境の違いであって間違いではありません。

iscsid を止めてはいけない理由#

iscsid は名前だけ見ると Kubernetes と無関係に見えます。しかも systemd の依存関係には現れません。kubelet.service の Requires= にも After= にも iscsid は書かれていません。それでも止めるとボリュームが外れます。

根拠を実機で示します。

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

$ sudo LC_ALL=C ss -tnp state established '( dport = :3260 )'

実行結果：

Recv-Q Send-Q Local Address:Port    Peer Address:PortProcess
0      0      192.168.1.129:38284 10.244.119.177:3260 users:(("iscsid",pid=1125,fd=9))
0      0      192.168.1.129:38266 10.244.119.177:3260 users:(("iscsid",pid=1125,fd=8))
0      0      192.168.1.129:38244 10.244.119.177:3260 users:(("iscsid",pid=1125,fd=7))
0      0      192.168.1.129:38298 10.244.119.177:3260 users:(("iscsid",pid=1125,fd=10))

ソースポート・PID・宛先 IP は実行のたびに変わります。本数もボリュームの割り当て状況で変わります。手元の値が本書と一致しなくても問題ありません。見るべきは宛先ポートと相手です。

10.244.119.177 は Pod ネットワーク上の Longhorn インスタンスマネージャで、こちらが iSCSI のターゲット（3260/tcp）です。ノードの iscsid がイニシエータとしてそこへ接続し、ノード上にブロックデバイス（/dev/longhorn/…）を作ります。それを kubelet が Pod へマウントします。 つまりデータの通り道がノードの iscsid を経由しているので、これを止めるとボリュームが外れます。Pod 側からは何も見えないのに、ノード側のデーモン 1 つで成立している——これが「systemd の依存関係に出てこない」の中身です。

running だけ見ると見落とす — enabled も見る#

棚卸しの一覧は、いま動いているものだけでは足りません。もう一方の側から見ます。

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

$ LC_ALL=C systemctl list-unit-files --type=service --state=enabled --no-pager --no-legend

本書ラボでは 30 本が返りました。この中に、さきほどの running の一覧には現れなかったものが混ざっています。

running にも enabled にも出てこないのに、動きだすサービスがある#

もう一段あります。fwupd（ファームウェア更新デーモン）は、running の一覧にも出てきませんでした。では止める必要はないのかというと、そうではありません。ユニットの定義を読むと理由が分かります。

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

$ systemctl cat fwupd.service

実行結果（抜粋）：

# /usr/lib/systemd/system/fwupd.service
[Unit]
Description=Firmware update daemon
Documentation=https://fwupd.org/
Wants=modprobe@sd_mod.service
After=modprobe@sd_mod.service dbus.service
Before=display-manager.service
ConditionVirtualization=!container

[Service]
Type=dbus
TimeoutSec=180
RuntimeDirectory=motd.d
RuntimeDirectoryPreserve=yes
BusName=org.freedesktop.fwupd
ExecStart=/usr/libexec/fwupd/fwupd

この下には [Service] の残りが続きますが、[Install] セクションは最後まで現れません。手元で確認するときは systemctl cat fwupd.service | grep -c '\[Install\]' が 0 を返すことで確かめられます。

実際、本書ラボで最初に観察したときは fwupd と udisks2 が running の一覧に出ていました。ノードを起動してしばらく使っていると、dnf などが D-Bus 越しに呼び出して起きてくるためです。同じノードでも、見るタイミングで一覧が変わります。 棚卸しの結果を「その瞬間のスナップショット」として扱い、インストールされているものの一覧（次の H2）と突き合わせるのはこのためです。

disable と mask の違い#

止め方にも 2 段階あります。ここを混同していると「止めたはずのサービスが動いている」という状況に出会います。

実機で打つと、出力に違いが出ます。まず disable です。

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

$ sudo systemctl disable --now udisks2

実行結果：

Removed '/etc/systemd/system/graphical.target.wants/udisks2.service'.

次に mask です。

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

$ sudo systemctl mask fwupd

実行結果：

Created symlink '/etc/systemd/system/fwupd.service' -> '/dev/null'.

上が disable で、wants の symlink を消しただけです。下が mask で、/dev/null を指す symlink を作っています。ユニットの実体が /dev/null に置き換わるので、systemd はそのユニットを起動できません。確実に止めるなら mask まで打ちます。

サービスを止めたら、それを起こす timer も止める#

ここまでで <svc>.service を止める話をしてきました。しかし systemd では、サービスを起動するのはサービス自身とは限りません。timer・socket・path といった別のユニットが、必要になった瞬間にサービスを起こします。

対象のサービスに紐づくユニットをまとめて見ます。

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

$ LC_ALL=C systemctl list-unit-files 'fwupd*' --no-pager

実行結果：

UNIT FILE             STATE   PRESET
fwupd-refresh.service static  -
fwupd.service         masked  disabled
fwupd-refresh.timer   enabled enabled

3 unit files listed.

fwupd.service は masked になっています。ところが fwupd-refresh.timer が enabled のまま残っています。この timer は fwupd-refresh.service（static）を定期的に起こし、その中身は /usr/bin/fwupdmgr refresh です。本体を封じても、周辺のユニットは動き続けます。

ノード全体で有効な timer も見ておきます。

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

$ LC_ALL=C systemctl list-unit-files --type=timer --state=enabled --no-pager --no-legend

実行結果：

dnf-makecache.timer enabled enabled
fstrim.timer        enabled enabled
fwupd-refresh.timer enabled enabled
logrotate.timer     enabled enabled
raid-check.timer    enabled enabled

パッケージの棚卸し#

サービスを止めても、パッケージが入っている限りバイナリはディスク上に残ります。攻撃者が別の経路で実行できてしまうので、footprint reduction は最終的に「入っていない状態」を目指します。まず数えます。

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

$ rpm -qa | wc -l

実行結果：

461

461 本を 1 つずつ見るのは現実的ではありません。dnf には「どのパッケージからも依存されていないもの」を挙げる機能があるので、そこから当たりを付けます。

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

$ sudo dnf repoquery --unneeded

メタデータのキャッシュ状態によっては、先頭に Last metadata expiration check: … の 1 行が付きます。以下はその行を除いた本体です。

実行結果：

binutils
binutils-gold
dracut-network
dracut-squash
erofs-utils
ethtool
gnupg2-smime
kdump-utils
libgusb
libsecret
makedumpfile
pcsc-lite
pcsc-lite-ccid
pcsc-lite-libs
pinentry
snappy

では、役割で判断するとどうなるか。本書ラボの k8s-wl-02 で「サーバとして明らかに不要」と言えるものは次のとおりです。

この 6 群は repoquery --unneeded の 16 本には入っていません。逆に、16 本のうち 3 群は残すべきものでした。2 つのリストは重ならない——これが「ツールの判定と役割の判断は別物」ということの実際の姿です。

本番では削除するより、そもそも入れないほうが安全です。AlmaLinux の Minimal Install から始め、必要なものだけ足す。稼働中のノードからパッケージを消すのは、依存関係で予期しないものまで外れるリスクがあります。まず dnf remove --setopt=tsflags=test（実際には消さない試行）で巻き込みを確認してから実行してください。本書ラボの dnf は 4.20.0 で、このオプションが受理されることを実機で確認しています。実際の手順は やってみよう① のステップ5 で扱います。

カーネルモジュールも見る#

パッケージの下にもう 1 層あります。カーネルにロードされているモジュールです。使わないファイルシステムやプロトコルのモジュールは、それ自体が攻撃面になります。

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

$ lsmod | wc -l

実行結果：

89

89 行（ヘッダ 1 行を含む）です。lsmod は先頭に Module Size Used by というヘッダ行を出すので、ロード済みモジュールは 88 個になります。厳密に数えるなら lsmod | tail -n +2 | wc -l のようにヘッダを落としてください。

次に、CIS Benchmark が名指しするモジュールがロードされていないかを見ます。

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

$ lsmod | grep -E "cramfs|freevxfs|jffs2|hfs|squashfs|udf|usb_storage|dccp|sctp|rds|tipc|bluetooth|firewire"

実行結果は 1 行も返りません。CIS が名指しする上記 13 種は、1 つもロードされていません。Minimal Install から作ったノードだからです。

開放ポートと firewalld の突き合わせ — 無意味な穴を見つける#

ここからが本回の核心の 1 つ目です。開放ポートの棚卸しは、2 つの側から見て、突き合わせて初めて意味を持ちます。片側だけを見ても「安全かどうか」は分かりません。

まずプロセス側です。生の出力を全量で載せます。手元で同じコマンドを打って、並べて読んでください。

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

$ sudo LC_ALL=C ss -ltnup

実行結果：

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
udp   UNCONN 0      0      192.168.1.129:7946       0.0.0.0:*    users:(("speaker",pid=3483,fd=9))
udp   UNCONN 0      0          127.0.0.1:323        0.0.0.0:*    users:(("chronyd",pid=979,fd=4))
udp   UNCONN 0      0              [::1]:323           [::]:*    users:(("chronyd",pid=979,fd=5))
tcp   LISTEN 0      4096   192.168.1.129:7946       0.0.0.0:*    users:(("speaker",pid=3483,fd=8))
tcp   LISTEN 0      4096       127.0.0.1:17472      0.0.0.0:*    users:(("speaker",pid=3483,fd=13))
tcp   LISTEN 0      4096       127.0.0.1:41927      0.0.0.0:*    users:(("containerd",pid=1079,fd=16))
tcp   LISTEN 0      4096       127.0.0.1:9099       0.0.0.0:*    users:(("calico-node",pid=4598,fd=4))
tcp   LISTEN 0      8            0.0.0.0:179        0.0.0.0:*    users:(("bird",pid=4817,fd=7))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=1075,fd=7))
tcp   LISTEN 0      4096       127.0.0.1:10249      0.0.0.0:*    users:(("kube-proxy",pid=2582,fd=11))
tcp   LISTEN 0      4096       127.0.0.1:10248      0.0.0.0:*    users:(("kubelet",pid=2093,fd=15))
tcp   LISTEN 0      4096               *:10256            *:*    users:(("kube-proxy",pid=2582,fd=12))
tcp   LISTEN 0      4096               *:10250            *:*    users:(("kubelet",pid=2093,fd=18))
tcp   LISTEN 0      4096               *:9100             *:*    users:(("node_exporter",pid=2576,fd=4))
tcp   LISTEN 0      4096               *:9120             *:*    users:(("speaker",pid=3483,fd=14))
tcp   LISTEN 0      128             [::]:22            [::]:*    users:(("sshd",pid=1075,fd=8))

PID と行の並び順は実行のたびに変わります。containerd の 41927 のような 5 桁のポート番号も、サービスが起動するたびに変わります（一時的に割り当てられる番号なので、覚える意味はありません）。手元の値が本書と違っても問題ありません。16 個の待ち受けがあり、ヘッダ 1 行を含めて 17 行です。

次にファイアウォール側です。こちらも全量で載せます。

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

$ sudo LC_ALL=C firewall-cmd --list-all

実行結果：

public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports: 10250/tcp 30000-32767/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

この 2 つを突き合わせると、次の表になります。「必要」「経路依存」「外から届かない」の 3 種類に分かれます。

突き合わせて見つかるのは「余分な穴」だけではない — 足りない許可も見つかる#

上の表で 7946/tcp+udp（MetalLB の speaker）を「経路依存」と書きました。この判定は保留です。プロセスは 192.168.1.129、つまり管理ネットワーク側の IP で待ち受けているのに、その経路の public ゾーンには許可がありません。BGP のように内部ネットワーク（eth1）へ逃げているわけでもありません。

ここは推測せずに、当のプロセスに聞きます。MetalLB の speaker は、memberlist という仕組みでノード同士が合意を取ります。 合意が取れているかどうかは、ログに出ます。

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

$ kubectl -n metallb-system logs -l app.kubernetes.io/component=speaker --tail=200 | grep 'partial join' | tail -1

実行結果（横に長いので、コードブロックの中で横スクロールします。読み取るのは expected と joined の 2 つです）：

{"caller":"speakerlist.go:281","error":"4 errors occurred:\n\t* Failed to join 192.168.1.126:7946: dial tcp 192.168.1.126:7946: connect: no route to host\n\t* Failed to join 192.168.1.125:7946: dial tcp 192.168.1.125:7946: connect: no route to host\n\t* Failed to join 192.168.1.128:7946: dial tcp 192.168.1.128:7946: connect: no route to host\n\t* Failed to join 192.168.1.127:7946: dial tcp 192.168.1.127:7946: connect: no route to host\n\n","expected":4,"joined":0,"level":"error","msg":"partial join","op":"memberDiscovery","ts":"2026-07-27T06:02:10Z"}

それでも LoadBalancer の Service には外部 IP が付いており、https://fanclub.local/ は 200 を返しています。memberlist は「どのノードが生きているか」を speaker 同士で速く知り合うための仕組みで、これが使えない場合でも、speaker は Kubernetes API 側の情報にフォールバックして「どのノードが広告するか」を決められます。動くけれど、ノードが落ちたときの切り替えが遅くなる——そういう壊れ方です。壊れているのに動いているので、今まで誰も気づきませんでした。

speaker の再起動回数を見ると、痕跡が残っています。

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

$ kubectl -n metallb-system get pod -o wide

実行結果（抜粋）：

NAME                    READY   STATUS    RESTARTS       AGE   IP              NODE
metallb-speaker-2htkt   1/1     Running   39 (12m ago)   38h   192.168.1.126   k8s-cp-02
metallb-speaker-4dgzr   1/1     Running   20 (10m ago)   38h   192.168.1.129   k8s-wl-02
metallb-speaker-fhk2v   1/1     Running   39 (12m ago)   38h   192.168.1.125   k8s-cp-01
metallb-speaker-xmv6d   1/1     Running   19 (10m ago)   38h   192.168.1.128   k8s-wl-01
metallb-speaker-zhnjd   1/1     Running   38 (11m ago)   38h   192.168.1.127   k8s-cp-03

RESTARTS が 19〜39 回あります。STATUS は Running で READY も 1/1 なので、kubectl get pod をざっと眺めるだけでは異常に見えません。数字の列まで読む習慣がないと、この種の「静かな故障」は見つかりません。

# firewall-cmd --permanent --add-port=7946/tcp --add-port=7946/udp
# firewall-cmd --reload

ここで BGP と bird という語が出ました。BGP は Calico がノード間で「どの Pod がどのノードにいるか」を伝え合うために使う経路交換プロトコルで、bird はその実装デーモンです。179/tcp は firewalld で許可していないのに、BGP セッションは張れています。 なぜ通るのかは次のセクションで解明します。

listen していないのに開いているポート（Control Plane Node の実例）#

Control Plane Node 側も同じ 2 コマンドで見ます。ここは読み取りだけで、Control Plane Node には変更を加えません。

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

$ sudo LC_ALL=C firewall-cmd --list-all

実行結果：

public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports: 6443/tcp 10250/tcp 2379-2380/tcp 10257/tcp 10259/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

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

$ sudo LC_ALL=C ss -ltnup

実行結果：

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
udp   UNCONN 0      0      192.168.1.125:7946       0.0.0.0:*    users:(("speaker",pid=3339,fd=9))
udp   UNCONN 0      0          127.0.0.1:323        0.0.0.0:*    users:(("chronyd",pid=921,fd=4))
udp   UNCONN 0      0              [::1]:323           [::]:*    users:(("chronyd",pid=921,fd=5))
tcp   LISTEN 0      8            0.0.0.0:179        0.0.0.0:*    users:(("bird",pid=4096,fd=7))
tcp   LISTEN 0      4096       127.0.0.1:17472      0.0.0.0:*    users:(("speaker",pid=3339,fd=13))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=1000,fd=7))
tcp   LISTEN 0      4096   192.168.1.125:2379       0.0.0.0:*    users:(("etcd",pid=2096,fd=6))
tcp   LISTEN 0      4096   192.168.1.125:2380       0.0.0.0:*    users:(("etcd",pid=2096,fd=3))
tcp   LISTEN 0      4096       127.0.0.1:10257      0.0.0.0:*    users:(("kube-controller",pid=2237,fd=4))
tcp   LISTEN 0      4096       127.0.0.1:10259      0.0.0.0:*    users:(("kube-scheduler",pid=2330,fd=4))
tcp   LISTEN 0      4096       127.0.0.1:10248      0.0.0.0:*    users:(("kubelet",pid=1986,fd=23))
tcp   LISTEN 0      4096       127.0.0.1:10249      0.0.0.0:*    users:(("kube-proxy",pid=2584,fd=14))
tcp   LISTEN 0      4096   192.168.1.125:7946       0.0.0.0:*    users:(("speaker",pid=3339,fd=8))
tcp   LISTEN 0      4096       127.0.0.1:2379       0.0.0.0:*    users:(("etcd",pid=2096,fd=7))
tcp   LISTEN 0      4096       127.0.0.1:2381       0.0.0.0:*    users:(("etcd",pid=2096,fd=20))
tcp   LISTEN 0      4096       127.0.0.1:39579      0.0.0.0:*    users:(("containerd",pid=1008,fd=15))
tcp   LISTEN 0      4096       127.0.0.1:9099       0.0.0.0:*    users:(("calico-node",pid=3950,fd=4))
tcp   LISTEN 0      4096               *:10250            *:*    users:(("kubelet",pid=1986,fd=21))
tcp   LISTEN 0      128             [::]:22            [::]:*    users:(("sshd",pid=1000,fd=8))
tcp   LISTEN 0      4096               *:10256            *:*    users:(("kube-proxy",pid=2584,fd=12))
tcp   LISTEN 0      4096               *:6443             *:*    users:(("kube-apiserver",pid=2224,fd=4))
tcp   LISTEN 0      4096               *:9120             *:*    users:(("speaker",pid=3339,fd=14))
tcp   LISTEN 0      4096               *:9100             *:*    users:(("node_exporter",pid=2603,fd=4))

突き合わせると、2 つのポートは誰も待っていないことが分かります。

なぜこの 2 つが localhost にしか bind していないのか。根拠は static Pod のマニフェストにあります。

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

$ sudo grep -n "bind-address" /etc/kubernetes/manifests/kube-controller-manager.yaml

実行結果：

16:    - --bind-address=127.0.0.1

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

$ sudo grep -n "bind-address" /etc/kubernetes/manifests/kube-scheduler.yaml

実行結果：

15:    - --bind-address=127.0.0.1

見つけたら、どう塞ぐか。この 2 つは static Pod の引数を触る必要がなく、firewalld から外すだけで塞げます。参考として手順だけ示します。本回は Control Plane Node に変更を加えない方針なので実施しません。

実行コマンド（k8s-cp-01 上・root・本回では実施しません）：

# firewall-cmd --permanent --remove-port=10257/tcp --remove-port=10259/tcp
# firewall-cmd --reload

# は root プロンプトです。developer で sudo を付けて打っても同じです。自分の環境では 2 行で減らせる攻撃面なので、覚えておいてください。

もう 1 つ、etcd の 2379 についても見ておきます。192.168.1.125（管理ネットワーク）でも待ち受けているのは、kubeadm が生成した引数の帰結です。実機で確認できます。

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

$ sudo grep -n "listen-client-urls\|listen-peer-urls" /etc/kubernetes/manifests/etcd.yaml

実行結果：

23:    - --listen-client-urls=https://127.0.0.1:2379,https://192.168.1.125:2379
25:    - --listen-peer-urls=https://192.168.1.125:2380

使っていないのに開いているサービス#

k8s-wl-02 の firewall-cmd --list-all に戻ります。services: 行に cockpit がありました。cockpit は Web 管理コンソールで、9090/tcp を使います。本当に動いているのか確かめます。

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

$ rpm -q cockpit

実行結果：

package cockpit is not installed

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

$ systemctl is-enabled cockpit.socket

実行結果：

not-found

cockpit（9090/tcp）は firewalld で許可されているのに、パッケージ自体が入っていません。 AlmaLinux の既定ゾーン設定の名残です。dhcpv6-client（546/udp）も、静的 IP 運用の本書ラボでは不要です。この 2 つは削除できます——やってみよう① のステップ4 で外します。

ここまでのまとめ#

ここまでで、動いているもの（サービス）・入っているもの（パッケージ）・待っているもの（ポート）の 3 つを数えました。次の 2 セクションでは、そのポートが実際に届くかどうかは firewalld のゾーンで決まること、そして firewalld だけがパケットを止めているわけではないことを確認します。

ここまでのコマンドはすべて読み取りなので、手元のノードでもそのまま打って構いません（何も変わりません）。実際に手を入れるのは やってみよう① からです。

firewalld のゾーンモデル — 同じポートでも来る経路で結果が変わる#

核心の 2 つ目です。前節で、179/tcp（Calico の BGP）は public zone に許可が無いのに BGP セッションは張れていることが分かりました。「firewalld が効いていないのでは」と疑うのが自然ですが、実測すると逆です。

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

$ sudo LC_ALL=C ss -tnp state established '( dport = :179 )'

実行結果：

Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
0      0        10.0.10.129:60811  10.0.10.127:179  users:(("bird",pid=4817,fd=10))
0      0        10.0.10.129:42125  10.0.10.126:179  users:(("bird",pid=4817,fd=9))
0      0        10.0.10.129:48229  10.0.10.128:179  users:(("bird",pid=4817,fd=11))
0      0        10.0.10.129:49389  10.0.10.125:179  users:(("bird",pid=4817,fd=8))

ソースポートと PID は起動のたびに変わります。見るべきはローカル側のアドレスです。

BGP は 10.0.10.x（eth1・クラスタ内部）で、他の 4 ノードすべてと張られています（.125 / .126 / .127 は Control Plane Node、.128 は k8s-wl-01）。そしてそのレンジは trusted ゾーン（target: ACCEPT）に登録されています。ポートを開けたから通っているのではなく、ゾーンが ACCEPT だから通っているのです。

同じポートへ管理ネットワーク側から入ろうとすると、結果が変わります。

実行コマンド（k8s-wl-02 上・developer・的は k8s-wl-01 = 192.168.1.128）：

$ timeout 5 bash -c 'cat < /dev/null > /dev/tcp/192.168.1.128/179'

実行結果：

bash: connect: No route to host
bash: line 1: /dev/tcp/192.168.1.128/179: No route to host

同じノードの他のポートでも、同じ構図になります。いずれも k8s-wl-02 から k8s-wl-01 宛の実測です。

9100 宛は 179 と同じ 2 行のエラーが返り、10250 宛は何も出力せずに終了します（成功したという意味です）。Unix の作法どおり、うまくいったときは黙っています。終了コードで判定したい場合は、コマンドの直後に echo $? を打ってください（成功なら 0、拒否なら 1 です）。

ここまでを整理すると、firewalld のゾーンモデルは次の 4 点に集約できます。

firewalld だけがパケットフィルタではない#

Kubernetes ノード特有の事情がもう 1 つあります。nft list ruleset を読もうとすると、firewalld 以外のテーブルが大量に出てきます。まずテーブルの一覧だけを見ます。

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

$ sudo nft list tables

実行結果（抜粋）：

table inet firewalld
table ip filter
table ip nat
table ip mangle
table ip raw
table arp calico-arp

ip filter 以下は iptables-nft が管理しています。実際に覗くと、先頭に警告が出ます。

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

$ sudo nft list table ip filter

実行結果（先頭行）：

# Warning: table ip filter is managed by iptables-nft, do not touch!

誰が何行書いているかを数えると、firewalld は少数派だと分かります。

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

$ sudo iptables-save | grep -c cali
$ sudo iptables-save | grep -c KUBE-

実行結果：

548
373

数はクラスタの規模（Service 数・NetworkPolicy 数・Pod 数）で変わります。 手元の値が本書と違って当然です。見てほしいのは桁で、firewalld が書いている数十行に対して、Kubernetes 側が 3 桁のルールを積んでいる、という比率です。

INPUT チェーンの入り口を見ると、この同居の形が読み取れます。

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

$ sudo iptables -S INPUT

実行結果：

-P INPUT ACCEPT
-A INPUT -m comment --comment "cali:Cz_u1IQiXIMmKD4c" -j cali-INPUT
-A INPUT -m conntrack --ctstate NEW -m comment --comment "kubernetes load balancer firewall" -j KUBE-PROXY-FIREWALL
-A INPUT -m comment --comment "kubernetes health check service ports" -j KUBE-NODEPORTS
-A INPUT -m conntrack --ctstate NEW -m comment --comment "kubernetes externally-visible service portals" -j KUBE-EXTERNAL-SERVICES
-A INPUT -j KUBE-FIREWALL

cali: に続く 16 文字は Calico がルールを識別するために振るハッシュで、環境ごとに違います。手元の値が本書と一致しなくても問題ありません。

では、なぜ firewalld の許可が効いているのか。cali-INPUT の中身を見ると答えが出ます。

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

$ sudo iptables -S cali-INPUT

実行結果（先頭 3 行）：

-N cali-INPUT
-A cali-INPUT -p 4 -m comment --comment "cali:PajejrV4aFdkZojI" -m comment --comment "Allow IPIP packets from Calico hosts" -m set --match-set cali40all-hosts-net src -m addrtype --dst-type LOCAL -j ACCEPT
-A cali-INPUT -p 4 -m comment --comment "cali:_wjq-Yrma8Ly1Svo" -m comment --comment "Drop IPIP packets from non-Calico hosts" -j DROP

-p 4 は「IP プロトコル番号 4」＝ IPIP トンネルです。IPIP は Calico がノード間のパケットを別の IP パケットで包んで運ぶトンネル方式で、本書ラボの IPPool は ipipMode: Always です。ポート番号ではなく IP プロトコル番号なので、firewalld でも --add-port ではなく --add-protocol で扱います。

ここで名前の罠があります。プロトコル名は /etc/protocols を見て決めます。

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

$ grep -nE "^(ipv4|ipip)" /etc/protocols

実行結果：

18:ipv4	4	IPv4		# IPv4 encapsulation
110:ipip	94	IPIP		# Yet Another IP encapsulation

cali-INPUT の残りは、workload（Pod）から host への通信の分岐と、Calico の host endpoint 用の判定です。本書ラボは host endpoint を設定していないので、通常の INPUT は素通りし、その後 inet firewalld の filter_INPUT で評価されます。

なぜ firewalld のほうが後なのか。nftables のチェーンには優先度（priority）があり、同じフックにぶら下がる複数のチェーンは数字の小さい順に評価されます。nft list ruleset の該当行を見ると、それが読み取れます。

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

$ sudo nft list chain ip filter INPUT | head -3

実行結果：

# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
	chain INPUT {
		type filter hook input priority filter; policy accept;

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

$ sudo nft list chain inet firewalld filter_INPUT | head -3

実行結果：

table inet firewalld {
	chain filter_INPUT {
		type filter hook input priority filter + 10; policy accept;

filter は 0 を意味する定数なので、iptables-nft 側の INPUT（priority 0）が先、firewalld の filter_INPUT（priority 10）が後に評価されます。

プロキシは強制力を持たない — 外部アクセス最小化の出発点#

冒頭で予告した前提の話です。本書ラボは、第2巻から alma-proxy（Squid・whitelist 方式） を通して外部へ出る構成にしてきました。企業の出口制御を再現するための設計です。「だからノードは whitelist に載ったドメインにしか出られない」——これは誤りでした。

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' https://github.com/

実行結果：

200

プロキシを迂回して、直接インターネットへ出られます。 理由を分解します。

時刻同期でも同じことが起きています。

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

$ grep -E "^(server|pool)" /etc/chrony.conf

実行結果：

server time.cloudflare.com iburst
server 192.168.1.121 iburst

time.cloudflare.com は AlmaLinux の既定で、本書が足した内部 NTP（192.168.1.121）と両方が生きています。実際にどちらと同期しているかは chronyc -n sources で確認できます。事前観察では 162.159.200.123（Cloudflare の NTP）と実際に同期していることを確認しました（Reach 377）。出力の全量は やってみよう② のステップ3 で掲載します。

では、どうやって強制するか。答えは 2 つあります。

この 2 つは別の層であり、両方いります。Pod を NetworkPolicy で締めても、ノード上で直接動くプロセス（侵害された kubelet プラグイン、SSH で入った攻撃者のシェル）は NetworkPolicy の対象外です。

hostNetwork: true の Pod は「ノード自身」として扱われる#

「firewalld はノード、NetworkPolicy は Pod」と分けたばかりですが、その境目にいる Pod があります。数えてみます。

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

$ kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,HOSTNET:.spec.hostNetwork' --no-headers | grep true

本書ラボでは 32 個が該当しました。内訳は次のとおりです。

fanclub の Pod は 1 つも含まれません（hostNetwork は未設定＝ false です）。この違いが、外向き通信の扱いをそのまま分けます。

OS ユーザ・sudo・SSH の現状（least-privilege identity management）#

3 方向のうち「権限を絞る」に移ります。まず現状把握です。ここで見たものが、やってみよう④・⑤ の前提になります。

ユーザの棚卸し#

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

$ wc -l < /etc/passwd

実行結果：

24

24 行あります。全部を読む必要はありません。見るべきは「ログインシェルを持つのは誰か」です。

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

$ awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

返ってきたのは root と developer のほか、sync / shutdown / halt の 3 つでした。後者 3 つのシェルは /bin/sync /sbin/shutdown /sbin/halt という特殊シェルで、ログインには使えません。つまり 実際にログインシェルを持つのは root と developer の 2 つだけです。

もう 1 つ、パスワードでログインできるユーザも見ます。

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

$ sudo awk -F: '$2 ~ /^\$/ {print $1}' /etc/shadow

返ってきたのは developer の 1 行だけでした。root のパスワード欄は ! でロックされています。/etc/shadow の 2 列目は「$ + 方式 ID + $ + …」の形で、先頭がパスワードハッシュの方式を表します。developer は $y$ ＝ yescrypt でした。この awk は「2 列目が $ で始まる行」＝ ハッシュが設定されている行を拾っています。

sudo の棚卸し#

次に「誰が root になれるか」を見ます。

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

$ sudo ls -l /etc/sudoers.d/

実行結果：

total 4
-r--r-----. 1 root root 34 Jun 20 21:25 developer

developer という 34 バイトのファイル 1 つだけです。パーミッションは -r--r-----、オーナーは root:root です。中身を開きます。

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

$ sudo cat /etc/sudoers.d/developer

実行結果：

developer ALL=(ALL) NOPASSWD: ALL

本体側も見ます。

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

$ sudo grep -E "^(Defaults|%)" /etc/sudoers

実行結果：

Defaults   !visiblepw
Defaults    always_set_home
Defaults    match_group_by_gid
Defaults    always_query_group_plugin
Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
%wheel	ALL=(ALL)	ALL

本体の /etc/sudoers には %wheel ALL=(ALL) ALL（パスワードを要求する）があり、developer は wheel グループにも所属しています。それを上書きしているのが /etc/sudoers.d/developer の 1 行です。最後から 2 行目の Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin は、あとで効いてきます。

Defaults secure_path にも触れておきます。sudo で実行されるコマンドの PATH は、呼び出し元のシェルではなく secure_path の値に置き換わります。だから /usr/local/bin に置いたバイナリは sudo から見えません。第2回で kube-bench を /usr/bin に置いたのはこのためです。sudo の下では環境が変わる——これは ~ が /root に展開される話とも同じ系統で、「手元で動いたのに sudo だと動かない」の定番の原因です。この性質は やってみよう⑤ でもう一度効いてきます。

SSH の実効設定を読む#

/etc/ssh/sshd_config を読むのではなく、sshd -T で実効値を読みます。 drop-in や Include があると、ファイルを読むだけでは実際の値が分からないからです。

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

$ sudo sshd -T | sort

出力は 100 行以上あるので、堅牢化に効く項目だけを抜き出して表にします（openssh-server 9.9p1 の実測値です）。

ここで gssapiauthentication yes と x11forwarding yes が出ています。ところが /etc/ssh/sshd_config を開いても、この 2 行は見つかりません。どこから来ているのでしょうか。 drop-in ディレクトリを見ます。

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

$ sudo ls -l /etc/ssh/sshd_config.d/

実行結果：

total 12
-rw-r--r--. 1 root root  58 Jun 20 22:24 00-disable-password.conf
-rw-------. 1 root root 412 May 20 09:00 40-redhat-crypto-policies.conf
-rw-------. 1 root root 307 May 20 09:00 50-redhat.conf

3 つあります。中身を確認します。

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

$ sudo cat /etc/ssh/sshd_config.d/50-redhat.conf

実行結果：

SyslogFacility AUTHPRIV

ChallengeResponseAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials no

UsePAM yes

X11Forwarding yes

# It is recommended to use pam_motd in /etc/pam.d/sshd instead of PrintMotd,
# as it is more configurable and versatile than the built-in version.
PrintMotd no

やってみよう④ では、この 3 つに触らず新しい drop-in ファイルを 1 つ足します。本体もディストリビューションのファイルも書き換えずに済むので、切り戻しが 1 ファイルの削除で済みます。

やってみよう①：サービス・ポート・パッケージを棚卸しして削る#

対象は k8s-wl-02 の 1 台だけです。Control Plane Node では実施しません。

本文のコマンドは読みやすさのため kubectl と書いていますが、試験では alias k=kubectl が最初から設定されています（bash 補完も入っています）。本回はノード上の作業が中心で kubectl の比重は低いものの、クラスタ側の回帰確認では k get node と打てるほうが速いです。

ステップ1：3 つの側から現状を数える#

変更を加える前に、起点の数値を控えます。ステップ6 で同じものを数えて比べます。

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

$ LC_ALL=C systemctl list-units --type=service --state=running --no-legend | wc -l

実行結果：

22

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

$ LC_ALL=C systemctl list-unit-files --type=service --state=enabled --no-legend | wc -l

実行結果：

30

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

$ sudo ss -ltnup | wc -l

実行結果：

17

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

$ rpm -qa | wc -l

実行結果：

461

起点は running 22 本 / enabled 30 本 / ss -ltnup 17 行（ヘッダ 1 行を含むので待ち受けは 16 個）/ パッケージ 461 本です。この 4 つを控えておいてください。

ステップ2：止めてよいものを判断する#

棚卸しの表に照らして、次の 4 つを対象にします。

4 つのうち 3 つは、いま動いていません。 それでも止めるのは、「動いていない」と「動きえない」が別だからです。gssproxy だけが running の一覧に出ていた——この非対称は、ステップ6 で数を比べるときにもう一度出てきます。

ステップ3：disable と mask を打つ#

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

$ sudo systemctl disable --now fwupd udisks2 gssproxy bluetooth

実行結果：

Removed '/etc/systemd/system/dbus-org.bluez.service'.
Removed '/etc/systemd/system/bluetooth.target.wants/bluetooth.service'.
Removed '/etc/systemd/system/graphical.target.wants/udisks2.service'.

4 つ指定したのに、消えた symlink は 3 本です。 fwupd は [Install] セクションを持たない（static）ので外す symlink がなく、gssproxy はもともと自動起動が無効だったので何も出ません。disable は「自動起動の symlink を外す」だけの操作だと分かります。

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

$ sudo systemctl mask fwupd udisks2 gssproxy bluetooth

実行結果：

Created symlink '/etc/systemd/system/fwupd.service' -> '/dev/null'.
Created symlink '/etc/systemd/system/udisks2.service' -> '/dev/null'.
Created symlink '/etc/systemd/system/gssproxy.service' -> '/dev/null'.
Created symlink '/etc/systemd/system/bluetooth.service' -> '/dev/null'.

こちらは 4 本すべてに symlink ができました。disable だけでは、他のユニットの Wants= / Requires= 経由や D-Bus 越しに起動する余地が残ります。2 段で打つのがこの演習の型です。

ステップ3-b：サービスを起こす timer も止める#

fwupd.service を封じても、それを呼ぶ側が残っています。関連ユニットを確認します。

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

$ LC_ALL=C systemctl list-unit-files 'fwupd*' --no-pager

実行結果：

UNIT FILE             STATE   PRESET
fwupd-refresh.service static  -
fwupd.service         masked  disabled
fwupd-refresh.timer   enabled enabled

3 unit files listed.

fwupd.service は masked になりましたが、fwupd-refresh.timer が enabled のままです。これを止めます。

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

$ sudo systemctl disable --now fwupd-refresh.timer

実行結果：

Removed '/etc/systemd/system/timers.target.wants/fwupd-refresh.timer'.

ステップ4：使っていない firewalld の許可を外す#

cockpit はパッケージ自体が入っておらず、dhcpv6-client は静的 IP 運用なので不要です。2 つとも外します。

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

$ sudo firewall-cmd --permanent --remove-service=cockpit

実行結果：

success

firewall-cmd は成功すると success の 1 行だけを返します。 以降に出てくる firewall-cmd も同じなので、本書では結果の掲載を省きます。何も出ないのは異常だと思ってください。

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

$ sudo firewall-cmd --permanent --remove-service=dhcpv6-client

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

$ sudo firewall-cmd --reload

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

$ sudo LC_ALL=C firewall-cmd --list-all

実行結果：

public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: ssh
  ports: 10250/tcp 30000-32767/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

services: の行が cockpit dhcpv6-client ssh から ssh だけになりました。9090/tcp（cockpit）と 546/udp（dhcpv6-client）が閉じたことになります。

ステップ5：不要パッケージを 1 つ削る#

サービスを止めても、パッケージが入っている限りバイナリはディスク上に残ります。攻撃者が別の経路で実行できてしまうので、footprint reduction は最終的に「入っていない状態」を目指します。本演習では、確実に不要で依存も浅い bluez を対象にします。

まず、消さずに試します。

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

$ sudo dnf remove --setopt=tsflags=test -y bluez

実行結果（末尾）：

Freed space: 3.3 M
DNF will only download packages, install gpg keys, and check the transaction.
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Complete!

tsflags=test を付けると、依存解決とトランザクションの検証だけを行い、実際には削除しません。 実行後も rpm -q bluez はインストール済みを返します。巻き込みが無いことを確認してから、本番の削除に進みます。

同じ確認は --assumeno でもできます。

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

$ sudo dnf remove --assumeno bluez

実行結果（末尾）：

Removing:
 bluez           x86_64           5.85-1.el10           @baseos           3.3 M

Transaction Summary
Remove  1 Package

Freed space: 3.3 M
Operation aborted.

対象は bluez 1 本・3.3 M だけで、他を巻き込みません。tsflags=test が「トランザクションを実際に試す」のに対し、--assumeno は「確認プロンプトに No と答える」動きです。どちらでもよいので、消す前に必ず一覧を見てください。

本番の削除に進みます。

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

$ sudo dnf remove -y bluez

実行結果（末尾）：

Running transaction
  Preparing        :                                                        1/1
  Running scriptlet: bluez-5.85-1.el10.x86_64                               1/1
Unit /etc/systemd/system/bluetooth.service is masked, ignoring.

  Erasing          : bluez-5.85-1.el10.x86_64                               1/1
  Running scriptlet: bluez-5.85-1.el10.x86_64                               1/1

Removed:
  bluez-5.85-1.el10.x86_64

Complete!

途中に Unit /etc/systemd/system/bluetooth.service is masked, ignoring. が混ざっています。パッケージのアンインストールスクリプトが bluetooth.service を止めようとして、すでに mask されているので何もしなかったという報告です。エラーではありません。

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

$ rpm -q bluez

実行結果：

package bluez is not installed

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

$ rpm -qa | wc -l

実行結果：

460

461 から 1 減って 460 になりました。バイナリがディスクから消えたので、もう「起動しうる」ことすらありません。

ステップ6：壊れていないことを確かめる#

まずノード側です。

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

$ LC_ALL=C systemctl --failed

実行結果：

  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

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

$ systemctl is-active kubelet containerd

実行結果：

active
active

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

$ LC_ALL=C systemctl list-units --type=service --state=running --no-legend | wc -l

実行結果：

21

enabled の数も見ておきます。

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

$ LC_ALL=C systemctl list-unit-files --type=service --state=enabled --no-legend | wc -l

実行結果：

28

クラスタ側からも確認します。

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

$ kubectl get node k8s-wl-02

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

$ kubectl get pod -A --field-selector spec.nodeName=k8s-wl-02 | grep -v Running

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

$ kubectl -n longhorn-system get volumes.longhorn.io

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

$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/

実行結果（最後の curl）：

200

ノードは Ready、Longhorn の 4 ボリュームは attached healthy、アプリは 200 を返しています。grep -v Running には Velero のバックアップ用ジョブ（Completed）が残りますが、これは正常です。Running 以外がすべて Completed なら問題ありません。

k8s-ops からは --noproxy '*' が必須です（付けないと Squid 経由になり 000 が返ります）。第5回で確定した作法です。

ステップ7：後片付け（元に戻す）#

本書ではここまでの変更を残したまま次回へ進みます（ハードニングの成果なので、戻す理由がありません）。ただし戻す手順は必ず持っておいてください。「元に戻す」は、思っているより難しい——それがこのステップの主題です。

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

$ sudo systemctl unmask fwupd udisks2 gssproxy bluetooth

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

$ sudo systemctl enable --now udisks2
$ sudo systemctl start gssproxy

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

$ sudo dnf install -y bluez

やってみよう②：ノードが直接インターネットへ出られることを確かめる#

対象は k8s-wl-02 です。

ステップ1：プロキシ設定の実体を確かめる#

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

$ cat /etc/profile.d/proxy.sh

実行結果：

export http_proxy="http://192.168.1.121:3128"
export https_proxy="http://192.168.1.121:3128"
export no_proxy="localhost,127.0.0.1,192.168.1.0/24,10.0.10.0/24,10.96.0.0/12,10.244.0.0/16,.svc,.cluster.local,k8s-lb,k8s-cp-01,k8s-cp-02,k8s-cp-03,k8s-wl-01,k8s-wl-02,alma-proxy,k8s-registry"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export NO_PROXY="$no_proxy"

全行が export、つまりシェルの環境変数を定義しているだけです。ログインシェルを経由しないプロセスには、そもそも届きません。

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

$ systemctl show containerd -p Environment

実行結果（横に長いので、コードブロックの中で横スクロールします）：

Environment=HTTP_PROXY=http://192.168.1.121:3128 HTTPS_PROXY=http://192.168.1.121:3128 NO_PROXY=127.0.0.1,localhost,192.168.1.0/24,10.0.10.0/24,10.96.0.0/12,10.244.0.0/16,.svc,.cluster.local,k8s-lb,k8s-cp-01,k8s-cp-02,k8s-cp-03,k8s-wl-01,k8s-wl-02,k8s-registry

プロキシ設定が環境変数と systemd drop-in の 2 箇所にしか無いことを、目で確認してください。どちらも「読んだプロセスだけが従う」ものです。

ステップ2：プロキシを迂回して外へ出てみる#

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' https://github.com/

実行結果：

200

ステップ3：時刻同期の出口も見る#

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

$ grep -E "^(server|pool)" /etc/chrony.conf

実行結果：

server time.cloudflare.com iburst
server 192.168.1.121 iburst

設定に書いてあるだけでは、実際にどちらと同期しているかは分かりません。実測します。

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

$ chronyc -n sources

実行結果：

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- 162.159.200.123               3   6   377    32   +101us[ +101us] +/-   63ms
^* 192.168.1.121                 2   6   377   114    -38us[  -55us] +/- 9819us

162.159.200.123 は Cloudflare の NTP サーバです。Reach の 377 は 8 進数で 11111111、つまり直近 8 回の問い合わせがすべて成功しているという意味です。^* が付いている 192.168.1.121 が実際に採用されている同期元で、^- の Cloudflare は候補として保持されています。採用されていなくても、通信は毎回外へ出ています。

ステップ4：何が言えるかを整理する#

この状態を「外部アクセスが最小化されている」とは呼べません。 強制するにはパケットの層で止めるしかない——それが次の演習です。

やってみよう③：firewalld の policy object で egress を絞る#

本回の主演習です。前の演習で見た「環境変数のプロキシには強制力が無い」という状態を、パケットの層で強制に変えます。

復旧は 2 行です。演習を始める前に、この 2 行を手元に控えておいてください。

実行コマンド（k8s-wl-02 上・developer・復旧用）：

$ sudo firewall-cmd --permanent --delete-policy=egress-guard
$ sudo firewall-cmd --reload

対象は k8s-wl-02 です。

ステップ0：policy object とは何か#

firewalld 2.x の policy object は、ゾーンとゾーンの間（あるいはホストとゾーンの間）を流れる通信にポリシーを当てる仕組みです。ゾーンが「入ってくる通信」を扱うのに対し、policy は方向を持った通信を扱えます。

つまり HOST → ANY を REJECT にして、必要な宛先だけ accept で穴を開ける——これが egress 制限の型です。

作る前に、既定の policy を見ておきます。

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

$ sudo LC_ALL=C firewall-cmd --get-policies

実行結果：

allow-host-ipv6 gateway-dmz-to-HOST gateway-lan-to-HOST gateway-lan-to-work gateway-lan-to-world gateway-world-to-HOST

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

$ sudo LC_ALL=C firewall-cmd --info-policy=allow-host-ipv6

実行結果：

allow-host-ipv6 (active)
  disable: no
  priority: -15000
  target: CONTINUE
  ingress-zones: ANY
  egress-zones: HOST
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
	rule family="ipv6" icmp-type name="mld-listener-done" accept
	rule family="ipv6" icmp-type name="mld-listener-query" accept
	rule family="ipv6" icmp-type name="mld-listener-report" accept
	rule family="ipv6" icmp-type name="mld2-listener-report" accept
	rule family="ipv6" icmp-type name="neighbour-advertisement" accept
	rule family="ipv6" icmp-type name="neighbour-solicitation" accept
	rule family="ipv6" icmp-type name="redirect" accept
	rule family="ipv6" icmp-type name="router-advertisement" accept

これから作る policy と方向が逆であることに注目してください。allow-host-ipv6 は ingress-zones: ANY / egress-zones: HOST、つまり外からホストへ入ってくる通信が対象です。IPv6 の近隣探索など、止めるとネットワークが成立しなくなるものを通しています。priority: -15000 という大きな負の値で、ほかのどの policy より先に評価されるように置かれています。

本書ラボの既定 policy は 6 本で、allow-host-ipv6 のみ active、他は disabled です。既定で 6 本あるということは、policy object は特殊な機能ではなく firewalld の標準的な部品だということです。

ステップ1：現状を測る（before）#

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' https://github.com/

実行結果：

200

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' -x http://192.168.1.121:3128 https://github.com/

実行結果：

200

プロキシ経由でも直接でも 200 です。 これを「直接は落とす・プロキシ経由は通す」に変えます。

ステップ2：policy を作る#

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

$ sudo firewall-cmd --permanent --new-policy=egress-guard

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-ingress-zone=HOST

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-egress-zone=ANY

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

$ sudo firewall-cmd --permanent --policy=egress-guard --set-target=REJECT

この時点では、まだ --reload していないので動作は変わりません。ここで --reload を打たないでください。 次のステップで例外を足してから反映します。

ステップ3：必要な宛先だけ許可して反映する#

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-rich-rule='rule family=ipv4 destination address=192.168.1.0/24 accept'

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-rich-rule='rule family=ipv4 destination address=10.0.0.0/8 accept'

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

$ sudo firewall-cmd --reload

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

$ sudo LC_ALL=C firewall-cmd --info-policy=egress-guard

実行結果：

egress-guard (active)
  disable: no
  priority: -1
  target: REJECT
  ingress-zones: HOST
  egress-zones: ANY
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
	rule family="ipv4" destination address="10.0.0.0/8" accept
	rule family="ipv4" destination address="192.168.1.0/24" accept

rich rule は打った順ではなく firewalld が並べ替えた順で表示されます。順序が本書と違っても、評価結果は同じです（どちらも accept なので競合しません）。

192.168.1.0/24 は管理ネットワーク（プロキシ・レジストリ・LB・他ノード）、10.0.0.0/8 はクラスタ内部ネットワークと Pod / Service の CIDR をまとめて含みます。policy の priority が -1 でゾーンより小さいので、policy はゾーンより先に評価されます。

ステップ4：効いたことを確かめる（after）#

5 つの通信を順番に試します。

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' https://github.com/

実行結果：

000

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' -x http://192.168.1.121:3128 https://github.com/

実行結果：

200

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

$ getent hosts k8s-lb

実行結果：

192.168.1.124   k8s-lb

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' http://k8s-registry:5000/v2/

実行結果：

200

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

$ timeout 8 curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://192.168.1.124:6443/livez

実行結果：

200

直接の https://github.com/ だけが 000 に変わりました。DNS もレジストリも API Server も生きています。

失敗の中身を見ます。-s の代わりに -sS を使うと、進捗表示は出さずにエラーだけを見せてくれます。実行コマンド（k8s-wl-02 上・developer）：

$ timeout 10 curl -sS -o /dev/null --noproxy '*' https://github.com/

実行結果：

curl: (7) Failed to connect to github.com port 443 after 1 ms: Could not connect to server

ステップ5：閉じすぎて壊してみる#

ここまでは 192.168.1.0/24 を丸ごと許可していました。「必要そうなものだけ列挙する」に変えると何が起きるかを確かめます。

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

$ sudo firewall-cmd --permanent --policy=egress-guard --remove-rich-rule='rule family=ipv4 destination address=192.168.1.0/24 accept'

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-rich-rule='rule family=ipv4 destination address=192.168.1.124/32 port port=6443 protocol=tcp accept'

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-rich-rule='rule family=ipv4 destination address=192.168.1.123/32 port port=5000 protocol=tcp accept'

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

$ sudo firewall-cmd --permanent --policy=egress-guard --add-rich-rule='rule family=ipv4 destination address=192.168.1.121/32 port port=3128 protocol=tcp accept'

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

$ sudo firewall-cmd --reload

変更後の policy を見ておきます。

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

$ sudo LC_ALL=C firewall-cmd --info-policy=egress-guard

実行結果（末尾の rich rules のみ）：

  rich rules:
	rule family="ipv4" destination address="10.0.0.0/8" accept
	rule family="ipv4" destination address="192.168.1.121/32" port port="3128" protocol="tcp" accept
	rule family="ipv4" destination address="192.168.1.123/32" port port="5000" protocol="tcp" accept
	rule family="ipv4" destination address="192.168.1.124/32" port port="6443" protocol="tcp" accept

192.168.1.0/24 の一括許可が消え、宛先ホストとポートを名指しした 3 本に置き換わりました。「API Server・レジストリ・プロキシがあれば十分だろう」という、もっともらしい設計です。確かめます。

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

$ timeout 5 curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://192.168.1.124:6443/livez

実行結果：

200

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

$ timeout 5 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' http://192.168.1.123:5000/v2/

実行結果：

200

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

$ timeout 5 curl -s -o /dev/null -w '%{http_code}\n' -x http://192.168.1.121:3128 https://github.com/

実行結果：

200

3 つとも 200 です。ここで「問題なし」と結論を出したくなります。 ですが、同じレジストリにホスト名でアクセスすると結果が変わります。

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

$ timeout 8 curl -sS -o /dev/null --noproxy '*' http://k8s-registry:5000/v2/

実行結果：

curl: (6) Could not resolve host: k8s-registry

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

$ getent hosts k8s-lb

何も出力されません。 直後に echo $? を打つと 2（該当なし）が返ります。ステップ4 では 192.168.1.124 k8s-lb と返っていた同じコマンドです。

ノード間の通信も見ます。

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

$ timeout 5 bash -c 'cat < /dev/null > /dev/tcp/192.168.1.128/10250'

実行結果：

bash: connect: No route to host
bash: line 1: /dev/tcp/192.168.1.128/10250: No route to host

さきほどまで通っていた 10250 が落ちました。7946 も同じく No route to host になりますが、こちらは元から通っていなかったので、ここでは変化が観測できません。

ステップ6：元に戻し、クラスタが回復したことを確かめる#

まず policy を消します。

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

$ sudo firewall-cmd --permanent --delete-policy=egress-guard

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

$ sudo firewall-cmd --reload

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

$ sudo LC_ALL=C firewall-cmd --get-policies

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

$ timeout 8 curl -s -o /dev/null -w '%{http_code}\n' --noproxy '*' https://github.com/

実行結果：

200

--get-policies は既定の 6 本に戻り、直接の外向き通信も 200 に戻りました。名前解決も戻っています（getent hosts k8s-lb が 192.168.1.124 k8s-lb を返します）。ここで終わりにしてはいけません。 ステップ5 で DNS と kubelet 間通信を実際に落としているので、戻ったことを確認するまでが演習です。

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

$ kubectl get node

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

$ kubectl -n metallb-system get pod -o wide

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

$ kubectl -n metallb-system logs -l app.kubernetes.io/component=speaker --tail=20 --prefix

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

$ kubectl -n fanclub logs -l app=fanclub-backend -c backend --tail=5 --prefix

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

$ kubectl -n longhorn-system get volumes.longhorn.io

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

$ kubectl get gateway -A

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

$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/

確認する内容は次のとおりです。

kubectl get node の実行結果：

NAME        STATUS   ROLES           AGE   VERSION
k8s-cp-01   Ready    control-plane   44h   v1.36.3
k8s-cp-02   Ready    control-plane   41h   v1.36.3
k8s-cp-03   Ready    control-plane   41h   v1.36.3
k8s-wl-01   Ready    <none>          41h   v1.36.3
k8s-wl-02   Ready    <none>          41h   v1.36.3

kubectl get gateway -A の実行結果：

NAMESPACE   NAME              CLASS     ADDRESS         PROGRAMMED   AGE
fanclub     fanclub-gateway   traefik   192.168.1.200   True         35h

最後の curl の実行結果：

200

ステップ7：本番ではどう設計するか#

正しい順序は「閉じてから開ける」ではなく、「まず観測してから閉じる」です。

1. ss -tnp state established を一定期間サンプリングして、そのノードが実際にどこへ出ているかを記録する
2. 監視・ログ・バックアップ・時刻同期のエージェントを洗い出す（これらは通信先が広い）
3. クラスタ内部ネットワークの CIDR は丸ごと許可する（本演習のステップ3 の形）。ポート単位で絞るのは、内部通信の全量を把握できている場合に限る
4. 1 台で試してから展開する。全ノードに同時適用すると、壊れたときに切り分けるための健全なノードが残らない
5. ロールバック手順を先に書く（policy object は --permanent --delete-policy + --reload）

やってみよう④：sshd を drop-in で締める#

対象は k8s-wl-02 です。

ステップ1：実効値を控える（before）#

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

$ sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|gssapiauthentication|x11forwarding|allowtcpforwarding|maxauthtries|logingracetime|clientaliveinterval)"

実行結果：

logingracetime 120
maxauthtries 6
clientaliveinterval 0
permitrootlogin without-password
gssapiauthentication yes
passwordauthentication no
x11forwarding yes
allowtcpforwarding yes

grep は元の出力の順序を保つので、アルファベット順にはなりません（並べたいときは末尾に | sort を足してください）。この 8 行を控えておき、ステップ3 のあとで同じコマンドを打って見比べます。

ステップ2：drop-in ファイルを作る#

drop-in 方式が成立する根拠を、記憶ではなく実物で確かめます。

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

$ sudo grep -n -i "^include" /etc/ssh/sshd_config

実行結果：

15:Include /etc/ssh/sshd_config.d/*.conf

作成するファイル /etc/ssh/sshd_config.d/50-hardening.conf の全量は次のとおりです。

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
GSSAPIAuthentication no
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

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

$ sudo tee /etc/ssh/sshd_config.d/50-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
GSSAPIAuthentication no
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
EOF

各行の意図は次のとおりです。

ステップ3：構文チェックしてから反映する#

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

$ sudo sshd -t

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

$ sudo systemctl reload sshd

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

$ sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|gssapiauthentication|x11forwarding|allowtcpforwarding|maxauthtries|logingracetime|clientaliveinterval)"

実行結果：

logingracetime 30
maxauthtries 3
clientaliveinterval 300
permitrootlogin no
gssapiauthentication no
passwordauthentication no
x11forwarding no
allowtcpforwarding no

ステップ1 で控えた 8 行と、同じ並びで見比べてください。7 項目が狙いどおりに変わり、passwordauthentication だけが no のままです。これは元から no だったものを、drop-in で明示して固定した結果です。とくに gssapiauthentication と x11forwarding は 50-redhat.conf が yes にしていたものを、こちらのファイルが先に読まれることで上書きできました。

drop-in に書いた残り 4 項目も、同じ要領で確認できます。

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

$ sudo sshd -T | grep -E "^(permitemptypasswords|kbdinteractiveauthentication|allowagentforwarding|clientalivecountmax)"

実行結果：

clientalivecountmax 2
kbdinteractiveauthentication no
permitemptypasswords no
allowagentforwarding no

書いた 12 項目すべてが sshd -T に反映されていることを確認できました。設定ファイルを置いただけで満足せず、実効値で確かめる——これが本節の型です。

sshd -t は成功すると何も出力しません（Unix の作法どおりです）。エラーがあれば行番号つきで出ます。systemctl reload sshd も同様に無出力です。この 1 コマンドを挟むかどうかで、ノードに入れなくなる事故が防げます。

ステップ4：新しいセッションで入れることを確かめる#

既存のセッションは閉じずに、別のターミナルから接続します。

実行コマンド（作業端末から）：

$ ssh developer@192.168.1.129 'hostname'

実行結果：

k8s-wl-02

鍵認証は生きています。root で入れなくなったことも確認します。

実行コマンド（作業端末から）：

$ ssh -o BatchMode=yes root@192.168.1.129 'hostname'

実行結果：

root@192.168.1.129: Permission denied (publickey).

PermitRootLogin no が効いています。-o BatchMode=yes を付けているのは、パスワードの入力待ちで止まらないようにするためです。スクリプトから疎通を確かめるときの定番オプションなので、覚えておくと便利です。

ステップ5：後片付け#

本回の以降の演習に影響しないので残して構いません（root ログインも SSH のポートフォワードも本書では使っていません）。ただし戻す手順は持っておいてください。

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

$ sudo rm -f /etc/ssh/sshd_config.d/50-hardening.conf

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

$ sudo sshd -t

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

$ sudo systemctl reload sshd

やってみよう⑤：最小権限の sudo を新規ユーザで設計する#

対象は k8s-wl-02 です。

シナリオはこうです。監視当番のオペレータに、ノードの状態を確認する権限だけを渡します。 ログの閲覧とサービスの状態確認はできるが、サービスの停止や設定変更はできない。この境界を sudoers で表現します。

ステップ1：ユーザを作る#

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

$ sudo useradd -m -s /bin/bash nodeops

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

$ sudo passwd -l nodeops

実行結果：

passwd: password changed.

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

$ id nodeops

実行結果：

uid=1001(nodeops) gid=1001(nodeops) groups=1001(nodeops)

wheel グループに入っていないことを確認してください。ここに入れてしまうと %wheel ALL=(ALL) ALL が効いて、これから書く制限が意味をなくします。

ステップ2：コマンドの実体パスを確かめる#

sudoers はフルパスで書きます。 そしてそのパスが実体と一致していないと、ルールは一致せず常に拒否されます。書く前に必ず確認します。

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

$ command -v systemctl journalctl ss

実行結果：

/usr/bin/systemctl
/usr/bin/journalctl
/usr/sbin/ss

ステップ3：許可するコマンドを決める#

ステップ4：ファイルを作って検証してから配置する#

壊れた sudoers ファイルを /etc/sudoers.d/ に置いてはいけません。 sudo はこのディレクトリの全ファイルをパースし、1 つでも壊れていれば全体を拒否します。つまり root を含む全ユーザが sudo を使えなくなります。

そこで 「一時ファイルに書く → 配置前に構文検証 → 検証が通ってから配置」 の順で進めます。

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

$ cat > /tmp/nodeops.sudoers <<'EOF'
Cmnd_Alias NODE_READ = /usr/bin/systemctl --no-pager status *, /usr/bin/systemctl is-active *, /usr/sbin/ss *, /usr/bin/journalctl --no-pager, /usr/bin/journalctl --no-pager *
Defaults:nodeops !authenticate
nodeops ALL=(root) NODE_READ
EOF

各行の意味は次のとおりです。

配置する前に構文を検証します。

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

$ sudo visudo -c -f /tmp/nodeops.sudoers

実行結果：

/tmp/nodeops.sudoers: parsed OK

検証が通ったので配置します。

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

$ sudo install -m 0440 -o root -g root /tmp/nodeops.sudoers /etc/sudoers.d/nodeops

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

$ sudo ls -l /etc/sudoers.d/

実行結果：

total 8
-r--r-----. 1 root root  34 Jun 20 21:25 developer
-r--r-----. 1 root root 236 Jul 27 15:07 nodeops

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

$ sudo visudo -c

実行結果：

/etc/sudoers: parsed OK
/etc/sudoers.d/developer: parsed OK
/etc/sudoers.d/nodeops: parsed OK

3 行すべてが parsed OK です。1 つでも壊れていれば、sudo は全体を拒否します。配置したあとにこれを打つのは、「置いたファイルが他のファイルと矛盾していないか」まで含めて確認するためです。

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

$ rm -f /tmp/nodeops.sudoers

ステップ5：効いていることを確かめる#

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

$ sudo -l -U nodeops

実行結果（末尾）：

User nodeops may run the following commands on k8s-wl-02:
    (root) /usr/bin/systemctl --no-pager status *, /usr/bin/systemctl is-active *, /usr/sbin/ss *, /usr/bin/journalctl --no-pager, /usr/bin/journalctl --no-pager *

この前に Matching Defaults entries for nodeops on k8s-wl-02: という長い行が出ます。そこには secure_path と、こちらが書いた !authenticate が含まれます。書いたものが読み取られているかを、この 1 コマンドで確認できます。

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

$ sudo -u nodeops sudo -n systemctl --no-pager status kubelet

実行結果（先頭）：

* kubelet.service - kubelet: The Kubernetes Node Agent
     Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/kubelet.service.d
             `-10-kubeadm.conf
     Active: active (running) since Mon 2026-07-27 14:47:00 JST; 20min ago
   Main PID: 2093 (kubelet)
      Tasks: 15 (limit: 48736)
     Memory: 95M (peak: 104.2M)
        CPU: 29.250s
     CGroup: /system.slice/kubelet.service

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

$ sudo -u nodeops sudo -n systemctl stop kubelet

実行結果：

Sorry, user nodeops is not allowed to execute '/bin/systemctl stop kubelet' as root on k8s-wl-02.

狙いどおり拒否されました。sudo -u nodeops sudo ... と sudo が二重になっているのは、いったん nodeops になってから、そのユーザとして sudo を試すためです。-n は「パスワードを聞かれたら即座に失敗する」オプションで、入力待ちで止まらないようにしています。

もう 1 つ、ページャ経由の抜け道が塞がっているかも確かめておきます。

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

$ sudo -u nodeops sudo -n systemctl status kubelet

実行結果：

Sorry, user nodeops is not allowed to execute '/bin/systemctl status kubelet' as root on k8s-wl-02.

NODE_READ に書いたのは status / is-active / ss / journalctl の 4 種類だけなので、状態を見ることはできても、状態に手を入れることはできません。監視当番に渡す権限としては、これで足ります。

ステップ6：後片付け#

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

$ sudo rm -f /etc/sudoers.d/nodeops

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

$ sudo visudo -c

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

$ sudo userdel -r nodeops

Kubernetes を壊さない境界（必要通信の一覧）#

「閉じすぎると壊れる」を演習で確認したので、判断軸を表にまとめます。試験で「どこまで閉じるのが正解か」を決めるときの下敷きになります。

Control Plane Node の必要通信#

Workload Node の必要通信#

この 2 つの表から、試験でも実務でも使える判断軸が 4 行にまとまります。

1. クラスタ内部ネットワークの CIDR は丸ごと許可する。 ポート単位で絞る価値より、壊すリスクのほうが大きい
2. ノードとノードの通信は、思っているより多い。 kubelet・CNI・LoadBalancer・監視の 4 系統を必ず数える
3. 外向き（egress）を絞るときは、DNS / NTP / レジストリ / プロキシ / API Server の 5 つを先に許可する
4. 1 台で試して、監視が正常なまま数時間経ってから展開する

暗記必須コマンド（ホスト OS 堅牢化）#

この表で最も使う頻度が高いのは ss -ltnup と sshd -T の 2 つです。どちらも「設定ファイルに何と書いてあるか」ではなく「いま実際にどうなっているか」を答えてくれるコマンドです。ハードニングの作業では、この 2 つを起点にしてください。

まとめ#

本回では次の点を確認しました。

• ノード OS は 3 方向で削る。動かすものを減らす / 権限を絞る / 出口を狭める
• 棚卸しは running と enabled の両方を見る。bluetooth / sssd は running の一覧に出てこない
• disable では依存経由の起動を止められない。 確実に止めるなら mask。戻すときは unmask が要る
• running にも enabled にも出てこないのに動きだすサービスがある。 fwupd / udisks2 は Type=dbus で、呼ばれた瞬間に起きてくる。だから mask が要る
• サービスを止めたら、それを起こす timer も止める。 fwupd.service を mask しても fwupd-refresh.timer は残り、systemctl --failed に fwupd-refresh.service が並ぶ
• iscsid を止めると Longhorn のボリュームが外れる。 systemd の依存関係には現れないので、ss -tnp で通信を確認してから止める
• dnf repoquery --unneeded は「不要」の意味ではない。 ethtool / kdump-utils / makedumpfile / dracut-network など障害対応で必要な道具が挙がる。消してよいかは、ツールの判定ではなく役割で決める
• ss の bind アドレスと firewall-cmd --list-all を突き合わせる。 Control Plane Node の 10257 / 10259 は localhost bind なのに開いていた（無意味な穴）
• firewalld は経路（ゾーン）で結果が変わる。 BGP が通っていたのは eth1 が trusted だったから。192.168.1.x 側からは No route to host で弾かれる
• Kubernetes ノードのパケットフィルタは 3 者の共同管理。 Calico 548 行・kube-proxy 373 行が iptables-nft 側にあり、firewalld は inet firewalld テーブルにいる
• 環境変数のプロキシに強制力は無い。 ノードは --noproxy '*' で github へ 200 を返し、chrony は Cloudflare と直接同期している。「whitelist プロキシがあるから安全」は成立しない
• 強制するなら firewalld の policy object。 HOST → ANY を REJECT にして、必要な宛先だけ accept する。--permanent 専用なので、削除手順とセットで実施する
• REJECT は 1 ms で失敗し、DROP はタイムアウトまで待つ
• 棚卸しは「余分な穴」だけでなく「足りない許可」も見つける。 MetalLB の memberlist（7946）はクラスタ構築時から一度も張れていなかった（speaker のログが "joined":0）。それでも LoadBalancer は動いていたので、誰も気づかなかった
• 閉じすぎるとまず DNS が落ちる。 しかも IP 直指定のテストでは気づけない（curl http://192.168.1.123:5000/v2/ は 200 のまま、curl http://k8s-registry:5000/v2/ は Could not resolve host）。ノードは Ready のままなので監視も鳴らない
• 逆に、塞いだのに壊れないものもある。 ノード間の 10250 を塞いでも kubectl logs は成功する（あれは API Server から入ってくる通信だから）。影響範囲は、通信の向きまで見ないと判断できない
• sshd -T で実効値を読み、drop-in で締め、sshd -t を通してから reload する
• sudo はコマンド単位で与える。 エディタ・ページャ・find を許可すると、実質的に root を与えたのと同じになる。systemctl status は --no-pager を前置きで固定する

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

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

1. 本書ラボのノードは alma-proxy の whitelist を経由しなければ外部へ出られない
2. systemctl list-units --type=service --state=running を見れば、稼働サービスの棚卸しとしては十分である
3. systemctl mask したユニットは、systemctl start を打っても起動を拒否される
4. Workload Node の iscsid は Kubernetes のコンポーネントではないので停止してよい
5. firewalld で許可されているポートは、必ずそのノードのいずれかのプロセスが待ち受けている
6. Calico と kube-proxy は、firewalld とは別のテーブル（iptables-nft が管理）にルールを書いている
7. firewalld の policy object は --permanent を付けずに作成し、--reload で破棄できる
8. --set-target=REJECT で拒否された通信は、DROP と違って即座に失敗する
9. hostNetwork: true の Pod の外向き通信は、ノード自身の通信として firewalld の egress policy の対象になる

次回予告#

第8回「Pod Security Standards + Admission（Gatekeeper / ValidatingAdmissionPolicy）」では、D3 を終えて D4 ワークロード防御へ進みます。第6回で個別に扱った seccomp・capabilities・runAsNonRoot といった部品が、PSS の Restricted プロファイルという束として namespace 単位で強制される仕組みを扱います。

本回まではノード 1 台ずつ手で締めてきましたが、次回はクラスタ全体に対して、入口で自動的に弾くという方向に変わります。「1 台ずつ配って、配り忘れたノードが穴になる」という本回の弱点が、Admission ではどう解消されるのかを見比べてください。

→ 詳しくは 第8回 Pod Security Standards + Admission（Gatekeeper / ValidatingAdmissionPolicy）

リンク