API Server堅牢化とkubeadm更新【CKS第5回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第5回です。第4回では「誰が、何をできるか」を RBAC と ServiceAccount トークンの側から絞りました。本回はその手前——リクエストが API Server に入る瞬間を扱います。

本回も白紙からは始めません。kubeadm が作ったクラスタには --authorization-mode=Node,RBAC も --enable-admission-plugins=NodeRestriction も最初から入っています。手つかずなのは匿名アクセスの扱いだけです。したがって本回の大半は「設定する」ではなく「既にあるものが何をどこまで止めているのかを測る」ことに時間を使います。

そのうえで、本回には手を動かす主題が 3 つあります。匿名アクセスを正しく締めること、第2回で保留した CIS 1.2.5 を恒久的に直すこと、そして v1.36.2 から v1.36.3 へのパッチアップグレードです。1 つ目には「CIS の Remediation どおりに直すと API Server が起動しなくなる」という山場があります。第2回の 1.2.5 と同じ構図の第 2 弾です。

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

本回は CKS ドメイン D2: Cluster Hardening（配点 15%） の後半にあたります。D2 は 4 つのコンピテンシーからなり、第4回が前 2 つ（RBAC と ServiceAccount）を担当しました。本回が担当するのは残る 2 つです。

RBAC そのものの実装は第4回で完了しています。本回で RBAC が出てくるのは、--as や auth can-i --list を測るための道具として使う場面だけです。

第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回: カーネル層の強制アクセス制御

本回の起点#

起点は第4回の完了状態です。第2巻から引き継いだ 9 VM 構成（Control Plane Node 3 台 + Workload Node 2 台 + 作業端末・レジストリ・LB・プロキシ）が稼働している前提で進めます。

アップグレードは第2巻で 1 度やっている#

本回の後半で扱うクラスタアップグレードは、本シリーズで初めてのテーマではありません。文脈を先に整理します。

本回は第2巻の手順をなぞり直す回ではありません。第2巻は「クラスタを維持するための運用作業」としてアップグレードを扱いました。本回は「公表済みの脆弱性を塞ぐための防御手段」として同じ操作を打ちます。手順の一部は同じでも、判断の基準が変わります。パッチとマイナーで何が違うのか、バージョンスキューがなぜ順序を決めるのかは、後半で改めて整理します。

この回のゴール#

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

• リクエストが API Server を通る 3 つの関門（認証 → 認可 → Admission）を、拒否メッセージから見分けられる
• 匿名アクセスで実際に何が取れるかを測り、リスクを自分の言葉で評価できる
• --anonymous-auth=false をそのまま入れると API Server が起動しなくなる理由を説明できる
• --authentication-config（AuthenticationConfiguration）で匿名を probe 用エンドポイントだけに限定できる
• ファイル参照フラグに 3 点セット（フラグ + volumeMounts + volumes）が必要な理由を、必要なケースと不要なケースの両方で説明できる
• kubelet のサービング証明書をクラスタ CA 署名へ切り替え、CIS 1.2.5 を恒久的に PASS にできる
• パッチアップグレードで CVE を塞ぎ、バージョンスキューの制約を踏まえて順序を組める
• 手で足した設定が kubeadm upgrade で消える理由を説明でき、kubeadm-config と kubelet-config の 2 つの ConfigMap へ移して恒久化できる

本回で扱わない範囲#

第2回から送られてきた宿題#

第2回では kube-bench の FAIL を 10 件から 5 件まで減らしました。そのとき 1.2.5（--kubelet-certificate-authority）だけは意図的に保留しています。Remediation のとおりにフラグを足すと kubectl logs と kubectl exec が x509 エラーで壊れたため、バックアップから戻したうえで「恒久対応は第5回」と送りました。

その宿題を本回で回収します。壊れた原因はフラグではなく kubelet 側の証明書運用にあります。kubelet のサービング証明書をクラスタ CA の署名に切り替えれば、同じフラグがそのまま機能します。

リクエストが API Server を通る 3 つの関門#

本回の背骨になる整理です。以降の各節が、この 3 層のどこかに対応します。kubectl であれ curl であれ、API Server に届いたリクエストは必ず次の順に判定されます。

ここで押さえておきたいのは、3 つのうち kubeadm が既定で締めているのは ② と ③ だけだという点です。--authorization-mode=Node,RBAC も --enable-admission-plugins=NodeRestriction も、kubeadm init が生成した /etc/kubernetes/manifests/kube-apiserver.yaml に最初から書かれています。手つかずなのは ① の認証層です。だから本回は ① から始めます。

なお、3 つを通過したリクエストが最終的に書き込まれる先は etcd です。etcd に保存されたあとの防御（保存時暗号化）は第9回、誰が何を通したかの記録（監査ログ）は第16回で扱います。本回の守備範囲は「etcd に届く前」です。

匿名アクセスの実力を測る#

CIS ベンチマークにも、多くのハードニング記事にも「匿名アクセスを無効にせよ」と書かれています。しかし本書はその前に、切らないと何が起きるのかを自分で測ります。CKS が問うのは設定値の暗記ではなく、その設定が何を守っているのかを踏まえた判断だからです。

匿名リクエストは「拒否される」のではなく「通過する」#

kube-apiserver の --anonymous-auth は既定で true です。kubeadm はこのフラグを明示しないので、マニフェストを検索しても見つかりません。書かれていない＝有効です。

この状態でクライアント証明書もトークンも持たないリクエストが届くと、API Server はそれを拒否せず、system:anonymous というユーザー・system:unauthenticated というグループとして認証を通します。つまり匿名リクエストは、認証層を通過した状態で認可層に進みます。

その先で何ができるかを決めているのは RBAC です。そして匿名に権限を与えているのは、クラスタに最初から入っている次の 1 本だけです。

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

$ kubectl get clusterrole system:public-info-viewer -o yaml

実行結果（metadata.managedFields などの自動付与フィールドを落として整形しています）：

kind: ClusterRole
metadata:
  name: system:public-info-viewer
rules:
- nonResourceURLs:
  - /healthz
  - /livez
  - /readyz
  - /version
  - /version/
  verbs:
  - get

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

$ kubectl get clusterrolebinding system:public-info-viewer -o yaml

実行結果（同じく整形しています）：

kind: ClusterRoleBinding
metadata:
  name: system:public-info-viewer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:public-info-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

subjects に system:unauthenticated が入っています。ここが匿名アクセスの入口です。

nonResourceURLs という指定#

nonResourceURLs は、Pod や Secret のようなリソースではない URL パスそのものに対する権限指定です。/healthz のように API リソースの形をしていないエンドポイントを許可するときに使います。第4回で扱った apiGroups / resources / verbs の組とは別枠で、1 つの Role の中に両方を書くこともできます。

匿名で実際に取れるもの#

実機で測った結果が次の表です。k8s-cp-01 上から、その API Server を直接叩いています（HAProxy を経由すると、どの API Server に当たったのか分からなくなるためです）。

この表の読み方には 2 段階あります。

1. 匿名で取れるのはバージョン情報です。Secret も Pod 一覧も取れません。ここだけを見れば被害は限定的に見えます
2. ただし 403 は「安全」を意味しません。403 が返っているということは、認証は通っているということです。落としているのは RBAC であり、RBAC は後から変わります

バージョン情報が漏れると何が起きるか#

/version から「このクラスタは v1.36.2 で動いている」と分かれば、攻撃者はその版に効く CVE を狙い撃ちできます。Kubernetes の脆弱性情報は公開されており、影響を受けるバージョン範囲も公表されています。裏を返せば、バージョンが読めるクラスタは「まだパッチを当てていない穴」を探されている前提で考える必要があります。

この一点が、本回の後半でアップグレードを扱う理由でもあります。匿名アクセスを締める（読ませない）ことと、パッチを当てる（読まれても効かない状態にする）ことは、同じリスクに対する2 方向からの対処です。どちらか一方では足りません。

やってみよう①：匿名で API Server を叩いて境界を確かめる#

ステップ1：匿名で /version を取る#

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

# curl -sk --noproxy '*' https://192.168.1.125:6443/version

実行結果：

{
  "major": "1",
  "minor": "36",
  "emulationMajor": "1",
  "emulationMinor": "36",
  "minCompatibilityMajor": "1",
  "minCompatibilityMinor": "35",
  "gitVersion": "v1.36.2",
  "gitCommit": "24e2b02af5543d7910c2bb074c7264df5a8f0467",
  "gitTreeState": "clean",
  "buildDate": "2026-06-11T18:09:09Z",
  "goVersion": "go1.26.4",
  "compiler": "gc",
  "platform": "linux/amd64"
}

-k は TLS 証明書の検証を省くオプションです。ここで確かめたいのは「証明書が正しいか」ではなく「資格情報を何も出さないリクエストが何を返すか」なので、検証は外しています。

ステップ2：probe が使う 3 パスのステータスを取る#

本文の判断材料は HTTP ステータスコードなので、本文を捨ててコードだけを出します。

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

# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/healthz
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/livez
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/readyz

実行結果：

200
200
200

本文を見たいときは -o /dev/null -w を外してください。3 パスとも ok が返ります。この 3 つが 200 であることが、あとの節で決定的な意味を持ちます。

ステップ3：403 の本文を読む#

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

# curl -sk --noproxy '*' https://192.168.1.125:6443/api
# curl -sk --noproxy '*' https://192.168.1.125:6443/api/v1/namespaces

実行結果（message フィールドの抜粋）：

forbidden: User "system:anonymous" cannot get path "/api"
namespaces is forbidden: User "system:anonymous" cannot list resource "namespaces"

ここで確認してほしいのは system:anonymous という文字列です。「認証されていないから弾かれた」のであれば、拒否メッセージにユーザー名は出てきません。ユーザー名が出ているということは、そのユーザーとして認証されたうえで認可に落とされたということです。

2 つのメッセージの違いにも注目してください。/api のほうは cannot get path——非リソース URL としての拒否です。/api/v1/namespaces のほうは cannot list resource "namespaces"——リソースとしての拒否です。nonResourceURLs とリソース権限が別枠であることが、拒否メッセージにもそのまま現れます。

ステップ4：匿名の権限一覧を出す#

第4回では impersonation（--as）で「その主体に何ができるか」を一覧しました。同じ手を匿名にも使えそうに見えます。まず素直に打ってみます。

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

$ kubectl auth can-i --list --as=system:anonymous

実行結果：

Error from server (Forbidden): selfsubjectrulesreviews.authorization.k8s.io is forbidden: User "system:anonymous" cannot create resource "selfsubjectrulesreviews" in API group "authorization.k8s.io" at the cluster scope

使えません。 しかもこの失敗そのものが、本節の結論を裏づけています。

kubectl auth can-i は、裏で SelfSubjectRulesReview（一覧のとき）や SelfSubjectAccessReview（単発のとき）というリソースを API Server に作成して問い合わせています。--as を付けると、その作成リクエスト自体がなりすました相手の権限で実行されるので、相手にその作成権限が無ければ問い合わせ自体が 403 になります。

第4回で ServiceAccount に対して --as が使えたのは、その主体が system:authenticated グループに属していたからです。このグループには system:basic-user という ClusterRole が既定で紐づいており、「自分に何ができるかを問い合わせる権限」が含まれています。system:unauthenticated にはそれが無い——匿名は「自分に何ができるか」すら聞けないほど狭い、ということです。

そこで、管理者が代理で問い合わせる形に変えます。Self の付かない SubjectAccessReview は「この主体はこの操作を許されるか」を第三者として尋ねるリソースで、作成するのは管理者自身なので匿名の権限に左右されません。

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

$ cat <<'EOF' | kubectl create -o jsonpath='{.status}{"\n"}' -f -
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
spec:
  user: system:anonymous
  groups:
  - system:unauthenticated
  nonResourceAttributes:
    path: /healthz
    verb: get
EOF

実行結果：

{"allowed":true,"reason":"RBAC: allowed by ClusterRoleBinding \"system:public-info-viewer\" of ClusterRole \"system:public-info-viewer\" to Group \"system:unauthenticated\""}

reason フィールドがどの ClusterRoleBinding のどの ClusterRole がどのグループに対して許可したのかを全部教えてくれます。前節で読んだ ClusterRole が、実際にこの許可を出している当人だと確定しました。

拒否されるほうも確かめます。path を /api に変えて同じコマンドを打つと、次のようになります。

実行結果（path: /api の場合）：

{"allowed":false}

リソースに対して聞きたいときは nonResourceAttributes を resourceAttributes に置き換えます。たとえば resource: secrets / verb: list で尋ねると、やはり {"allowed":false} が返ります。

ステップ5：200 が返ったパスと RBAC を対応づける#

前節で読んだ system:public-info-viewer の nonResourceURLs と、ステップ1〜3 の結果を突き合わせます。

200 が返ったパスと、ClusterRole に書かれたパスが完全に一致します。 匿名の権限は謎の内部仕様ではなく、kubectl get clusterrole で読める 1 本の RBAC で決まっています。

到達点#

ここまでで、次のように説明できる状態になりました。「匿名リクエストは認証を通過して system:anonymous になり、RBAC の system:public-info-viewer によって 4 パス（5 エントリ）の nonResourceURLs だけを許されている。取れるのはバージョン情報である」。

試験相当の粒度#

「匿名ユーザーが到達できるエンドポイントを調べよ」という 1 問で 4〜6 分が目安です。手数がいちばん少ないのは curl で直接叩くことで、次が SubjectAccessReview です。ステップ4 で見たとおり kubectl auth can-i --as=system:anonymous は使えないので、本番でも試験でも、匿名相手にはこの手が通らないことを先に知っておくのが時間の節約になります。system:public-info-viewer という ClusterRole 名を覚えておくと、kubectl get clusterrole system:public-info-viewer -o yaml の 1 発で答えが出ます。

--anonymous-auth=false を素直に入れるとどうなるか#

ここが本回最大の山場です。第2回の 1.2.5 と同じ「CIS のとおりにやると壊れる」構図の第 2 弾を、読者自身の手で再現します。

ステップ0：先にバックアップを取る（鉄則1）#

第2回の鉄則1 のとおり、/etc/kubernetes/manifests/ の外へ退避します。本回は複数の節でマニフェストを編集するので、ファイル名に回番号を入れておきます。

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

# cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak-05

このバックアップは やってみよう②（次節）でもそのまま流用します。 第4回までに入れた --profiling=false / --service-account-extend-token-expiration=false / --service-account-max-token-expiration=24h を含んだ状態なので、ここから戻せば第4回完了状態に復帰できます。

ステップ1：kube-bench の Remediation を読む#

第2回で入れた kube-bench で、該当項目だけを確認します。root は既定で kubeconfig を持たないので、先に KUBECONFIG を渡します。

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

# export KUBECONFIG=/etc/kubernetes/admin.conf
# kube-bench run --targets master --check 1.2.1

実行結果（抜粋）：

[WARN] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Manual)

== Remediations master ==
1.2.1 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the control plane node and set the below parameter.
--anonymous-auth=false

指示は明快です。フラグを 1 行足せ、と書いてあります。そのとおりにするとどうなるかを確かめます。

ステップ2：先に probe の構成を読む#

フラグを足す前に、kubeadm が生成した static Pod の probe を確認します。

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

# grep -A 12 -E 'livenessProbe|readinessProbe|startupProbe' /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果：

    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 192.168.1.125
        path: /livez
        port: probe-port
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    ports:
    - containerPort: 6443
--
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 192.168.1.125
        path: /readyz
        port: probe-port
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 250m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 192.168.1.125
        path: /livez
        port: probe-port
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs

-A 12 は 12 行先まで出すので、name: や volumeMounts: のような隣接フィールドも一緒に出てきます。読み取りたいのは httpGet と failureThreshold / periodSeconds の 3 つです。

ここが本節の核心です。3 つの probe はいずれも、クライアント証明書もトークンも持たない HTTPS リクエストです。つまり kubelet は自分が起動した API Server を、匿名ユーザーとして叩いて生死を判定しています。

叩いているパスは /livez と /readyz。やってみよう① のステップ2 で 200 を確認した 3 パスのうちの 2 つです。匿名を切れば、この 2 つも 401 になります。

ステップ3：Remediation のとおりに適用する#

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

# vi /etc/kubernetes/manifests/kube-apiserver.yaml

第2回で立てたアルファベット順の原則に従い、--allow-privileged の次に入れます。編集後の該当箇所：

    - --allow-privileged=true
    - --anonymous-auth=false
    - --authorization-mode=Node,RBAC

保存した瞬間に kubelet が static Pod を作り直します（鉄則2）。ここから約 4 分が観察時間です。

ステップ4：待ち時間にクラスタ全体を見る#

この待ち時間の観察が本節の教材価値です。 k8s-ops へ移り、いつもどおりの確認コマンドを打ってください。

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

$ kubectl get nodes
$ kubectl get pods -A | grep -v Running
$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/

実行結果：

NAME        STATUS   ROLES           AGE   VERSION
k8s-cp-01   Ready    control-plane   25h   v1.36.2
k8s-cp-02   Ready    control-plane   23h   v1.36.2
k8s-cp-03   Ready    control-plane   23h   v1.36.2
k8s-wl-01   Ready    <none>          23h   v1.36.2
k8s-wl-02   Ready    <none>          23h   v1.36.2

NAMESPACE   NAME                                                     READY   STATUS      RESTARTS   AGE
velero      fanclub-default-kopia-maintain-job-1785058568470-llqpr   0/1     Completed   0          3h
velero      fanclub-default-kopia-maintain-job-1785062468479-bccg6   0/1     Completed   0          115m
velero      fanclub-default-kopia-maintain-job-1785068865091-22ssg   0/1     Completed   0          8m40s

200

3 つとも平常どおりです。grep -v Running に引っかかっているのは Velero の定期ジョブ（Completed）だけで、異常ではありません。壊した本人の Pod は Running なので、この grep には出てきません——ここが次の観察につながります。

次に、壊した本人である kube-apiserver-k8s-cp-01 を名指しで見ます。

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

$ kubectl get pod kube-apiserver-k8s-cp-01 -n kube-system

実行結果：

NAME                       READY   STATUS    RESTARTS      AGE
kube-apiserver-k8s-cp-01   0/1     Running   1 (33s ago)   5m3s

STATUS は Running のままです。 異常が現れているのは READY の 0/1 と、数分おきに 1 ずつ増える RESTARTS だけ。STATUS の列しか見ない癖がついていると、この状態は素通りしてしまいます。

続いて Events を読みます。

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

$ kubectl describe pod kube-apiserver-k8s-cp-01 -n kube-system | tail -20

実行結果（Events の抜粋・時刻と発生元の列は省いています）：

Warning  Unhealthy  ...  Startup probe failed: HTTP probe failed with statuscode: 401
Normal   Killing    ...  Container kube-apiserver failed startup probe, will be restarted

匿名で /livez を叩いて、返ってきたコードも確かめます。

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

# curl -sk --noproxy '*' https://192.168.1.125:6443/livez

実行結果：

{"status":"Failure","message":"Unauthorized","code":401}

なぜ約 4 分かかるのか#

kill されるまでの時間は、ステップ2 で読んだ startupProbe の設定から計算できます。

10 秒おきに 24 回失敗して初めて「起動に失敗した」と判定され、コンテナが作り直されます。そして作り直されたコンテナも同じ理由で 401 を返すので、約 4 分周期の再起動ループになります。RESTARTS が数分おきに 1 ずつ増えていくのはこのためです。

ノード上では crictl で同じことが読めます。

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

# crictl ps -a | grep kube-apiserver

実行結果：

4b92dc09856b1  9ec369c0ddb96  34 seconds ago  Running  kube-apiserver  1  29e742dc39f6a  kube-apiserver-k8s-cp-01  kube-system
d6dc6f42e2ca5  9ec369c0ddb96  5 minutes ago   Exited   kube-apiserver  0  29e742dc39f6a  kube-apiserver-k8s-cp-01  kube-system

右から 4 列目が ATTEMPT です。0 が Exited、1 が Running——1 度作り直されたことがそのまま読み取れます。放置すれば 2、3 と増えていきます。

ATTEMPT の数字が増えているコンテナが並びます。API が落ちている間、真実を教えてくれるのは crictl だけです（鉄則2）。

この状態がいちばん気づきにくい#

気づくための現実的な手立ては 2 つです。ひとつは kubectl get pod -n kube-system -o wide | grep apiserver を変更のたびに打ち、READY と RESTARTS の 2 列を必ず見ること。もうひとつは監視側で kube_pod_container_status_restarts_total のような指標にアラートを張っておくことです。第2巻で入れた kube-prometheus-stack はこの手の異常を拾える位置にいます。

そして CIS はこれを教えてくれない#

壊れた状態のまま、もう一度 kube-bench を打ってみます。

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

# kube-bench run --targets master --check 1.2.1

1.2.1 は WARN から PASS に変わります。 master のスコアも 44 PASS / 5 FAIL / 11 WARN → 45 PASS / 5 FAIL / 10 WARN へ動きます——API Server が再起動ループに入っているにもかかわらず、です。

(Manual) は「手動確認が推奨される項目」という表示であって、「スコアに影響しない」という意味ではありません。 cis-1.12 の 1.2.1 は audit スクリプトを持っており、--anonymous-auth=false という文字列が見つかれば PASS を返します。 動いているかどうかは見ていません。

第2回では「chown etcd:etcd /var/lib/etcd は PASS になるがリスクはほとんど減らない」という例でベンチマーク通過 ≠ 安全を確認しました。本節はその裏面です。ベンチマークの指示どおりに直してクラスタを壊すと、ベンチマークのスコアはむしろ上がります。 自動評価ツールは「設定文字列があるか」しか見ておらず、その設定でクラスタが動くかどうかは見ていません。

ステップ5：復旧する（必須）#

ステップ0 のバックアップから戻します。

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

# cp /root/kube-apiserver.yaml.bak-05 /etc/kubernetes/manifests/kube-apiserver.yaml

復帰の確認は crictl で行ってください。kubectl は k8s-cp-02 / k8s-cp-03 が答えてしまうので、k8s-cp-01 が直ったことの証拠になりません。

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

# crictl ps | grep kube-apiserver
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/livez

実行結果（2 コマンド目）：

200

crictl ps（-a なし）の出力に ATTEMPT が 0 の新しいコンテナが出ていて、匿名 /livez が 200 に戻っていれば復旧です。kubectl --server=https://192.168.1.125:6443 get --raw=/healthz で ok を確認してもかまいません（--server で名指ししているので、この形なら k8s-cp-01 の答えになります）。

正しい締め方 ——--authentication-config で匿名を probe に限定する#

前節で分かったのは「匿名を全部切ると probe が死ぬ」ということでした。かといって全部許したままではバージョンが漏れます。Kubernetes には第 3 の選択肢があります。

AuthenticationConfiguration という設定ファイル#

--anonymous-auth は true か false の 2 択でした。これに対して --authentication-config は、匿名を許すパスを列挙する方式です。設定ファイルの全量は次のとおりです。

/etc/kubernetes/auth/anonymous.yaml：

apiVersion: apiserver.config.k8s.io/v1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

読み方は「匿名認証は有効だが、通用するのは conditions に挙げた 3 パスに対してだけ」です。それ以外のパスに匿名で来たリクエストは、認証層で 401 になります。/version も 401 になるので、バージョン漏えいが止まります。そして /livez と /readyz は許されているので、probe は通ります。

conditions のパス指定は完全一致です。/livez/etcd のようなサブパスは /livez の指定では通りません。必要なら個別に列挙します。

バージョンの前提 ——feature gate は要らない#

この機能（匿名エンドポイントの限定）は AnonymousAuthConfigurableEndpoints、設定ファイル方式そのものは StructuredAuthenticationConfiguration という feature gate で導入されました。前者は v1.31 で alpha、v1.32 で beta として入っています。

そこで気になるのは「ラボと試験環境で feature gate の指定が要るのか」です。実機で確かめました。

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

# crictl ps | grep kube-apiserver
# crictl exec <kube-apiserver のコンテナ ID> kube-apiserver --help | grep -i 'AnonymousAuth\|StructuredAuthentication'

結果は次のとおりでした。ラボの v1.36.2 でも、CKS 試験環境と同じ v1.35 系（registry.k8s.io/kube-apiserver:v1.35.6 のイメージで確認）でも、--feature-gates の一覧に AnonymousAuthConfigurableEndpoints と StructuredAuthenticationConfiguration は載っていません（残っているのは StructuredAuthenticationConfigurationEgressSelector と StructuredAuthenticationConfigurationJWKSMetrics の BETA 2 件だけです）。一覧から外れているのは GA 済みだからで、どちらのバージョンでも feature gate の指定なしに --authentication-config が使えます。

本書は「GA した版番号」を断定しません。確認したのは「v1.35 と v1.36 の実機で、feature gate を指定せずに動く」という事実だけです。feature gate の状態はマイナーごとに変わるので、自分のクラスタで --help を見て確かめる手順のほうを覚えてください。試験環境でも同じ手が使えます。

排他制約 ——2 つを両方書いてはいけない#

kube-apiserver --help の --authentication-config の説明には、次の一文があります。

--authentication-config string   File with Authentication Configuration to configure the JWT Token
                                 authenticator or the anonymous authenticator. Requires the
                                 StructuredAuthenticationConfiguration feature gate. This flag is
                                 mutually exclusive with the --oidc-* flags if the file configures the
                                 JWT Token authenticator. This flag is mutually exclusive with
                                 --anonymous-auth if the file configures the Anonymous authenticator.

最後の 1 文が該当します。設定ファイルが匿名認証を構成している場合、--anonymous-auth とは排他です。したがって前節で --anonymous-auth=false を入れたままなら必ず消してください。両方書くと API Server が起動しません。

ヘルプ本文には Requires the StructuredAuthenticationConfiguration feature gate とも書かれています。GA 後もヘルプ文言が残っている例で、ヘルプの文言と feature gate 一覧が食い違うことがあるという点も覚えておくと役に立ちます。判断材料としては --feature-gates の一覧のほうが確実です。

3 点セットが必要な理由（鉄則4 の実践）#

設定ファイルは /etc/kubernetes/auth/ に置きます。ここで鉄則4 が効きます。static Pod はコンテナなので、マウントしていないホストのディレクトリは見えません。 フラグだけ足しても、コンテナの中には /etc/kubernetes/auth/anonymous.yaml が存在せず、API Server は起動できません。

そこで 3 つを同時に足します。編集後の該当箇所（3 か所）：

    - --authentication-config=/etc/kubernetes/auth/anonymous.yaml

    volumeMounts:
    - mountPath: /etc/kubernetes/auth
      name: auth-config
      readOnly: true

  volumes:
  - hostPath:
      path: /etc/kubernetes/auth
      type: DirectoryOrCreate
    name: auth-config

3 つの対応関係は次のとおりです。

name（ここでは auth-config）が ② と ③ を結ぶキーです。綴りが 1 文字でも違うと Pod が起動しません。type: DirectoryOrCreate は「ディレクトリが無ければ作る」という指定で、kubeadm が既存の volumes に使っているのと同じ書き方です。

3 点セットが要らないケースと対比する#

ここは第2回で予告した対比です。第2回 やってみよう③ で足した --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt（本回の やってみよう④ で恒久的に足すのと同じフラグです）は、明らかにホスト上のファイルを参照するのに ② と ③ が要りませんでした。

理由は /etc/kubernetes/pki が k8s-certs という名前で既にマウント済みだからです。参照先がその配下にあるなら、フラグを足すだけでコンテナから見えます。

適用後に何が変わるか#

403 が 401 に変わったことが、この設定の効き目そのものです。適用前は「認証は通っていて、RBAC で落とされていた」。適用後は「認証の時点で落ちている」。関門が 1 つ手前に移りました。前節で確認した「403 は安全を意味しない」という懸念が、ここで解消されます。

そして --anonymous-auth=false のときと違い、API Server は再起動ループに入りません。probe が使う 2 パスは開いているからです。同じ防御効果を、probe を壊さずに得られます。

締めたあとに、同じ物差しをもう一度当てる#

この節の冒頭で「切る前に何が取れるかを測る」と決めました。締めたあとにも同じことをします。 開けたままにした 3 パスから、攻撃者は何を読めるのでしょうか。

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

# curl -sk --noproxy '*' 'https://192.168.1.125:6443/readyz?verbose'

実行結果（先頭 15 行・実際は 30 行前後）：

[+]ping ok
[+]log ok
[+]etcd ok
[+]etcd-readiness ok
[+]informer-sync ok
[+]poststarthook/start-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/storage-object-count-tracker-hook ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/start-system-namespaces-controller ok
[+]poststarthook/peer-endpoint-reconciler-controller ok

通ります。 ?verbose はクエリ文字列であってパスではないので、conditions の path: /readyz という完全一致には引っかからず、そのまま匿名で読めます。/livez?verbose も同じです。

読めるのは各内部チェックの名前と成否です。バージョン番号ほど直接的ではありませんが、etcd が同居しているのか、どの aggregator が動いているのか、といった構成の手がかりにはなります。

本回はこれを許容します。 probe と LB のために開けざるを得ないパスであり、ここを閉じると起動できなくなるからです。大事なのは「残っているリスクを把握したうえで許容する」ことで、「締めたから安全」で思考を止めないことです。 第2回で「ベンチマークを通しても安全とは限らない」と学んだのと同じ姿勢を、自分の設定にも向けます。

conditions に何を残すかは「匿名で叩いている全員」を洗い出してから決める#

# grep -nE 'httpchk|tcp-check|backend|server' /etc/haproxy/haproxy.cfg

22:backend k8s-cp-api
24:  option tcp-check
26:  server k8s-cp-01 192.168.1.125:6443 check
27:  server k8s-cp-02 192.168.1.126:6443 check
28:  server k8s-cp-03 192.168.1.127:6443 check
35:backend traefik-https
37:  server traefik 192.168.1.200:443 check

安全にしてもベンチマークは通らない#

この設定を入れたあとに kube-bench を打つと、1.2.1 は WARN のままです。1.2.1 が探しているのは --anonymous-auth=false というフラグの文字列であって、--authentication-config による限定は見ていないからです。

前節と合わせると、ベンチマークの限界が両方向から見えます。

危険にするとスコアは上がり、安全にしてもスコアは動きません。 ——順序が逆です。ベンチマークは出発点であって到達点ではない、という第2回の主張が、本回でより強い形で確かめられます。スコアの改善を「安全になった証拠」として報告すると、壊れたクラスタを成果として提出することになります。 実務では「WARN のまま残した項目について、なぜその判断をしたのかを記録に残す」ことが対応そのものになります。

やってみよう②：匿名エンドポイント限定を 3 台へ展開する#

ステップ1：バックアップを確認する#

k8s-cp-01 については、前節のステップ0 で取った /root/kube-apiserver.yaml.bak-05 をそのまま流用します（取り直し不要）。k8s-cp-02 / k8s-cp-03 では、それぞれの台で新たに取ります。

実行コマンド（k8s-cp-02 上・root / k8s-cp-03 でも同じ）：

# cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak-05

ステップ2：設定ファイルを置く#

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

# mkdir -p /etc/kubernetes/auth
# vi /etc/kubernetes/auth/anonymous.yaml

内容（全量）：

apiVersion: apiserver.config.k8s.io/v1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

保存したら権限を絞ります。

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

# chmod 600 /etc/kubernetes/auth/anonymous.yaml
# ls -l /etc/kubernetes/auth/

実行結果：

合計 4
-rw-------. 1 root root 168  7月 26 21:44 anonymous.yaml

API Server の設定ファイルは 600・所有者 root が既定の作法です。CIS ベンチマークにも /etc/kubernetes 配下のファイル権限を確認する項目群があり、第2回で kubelet 側の 2 件を修復しました。自分で足すファイルも同じ基準に合わせてください。

ステップ3：マニフェストに 3 点セットを足す#

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

# vi /etc/kubernetes/manifests/kube-apiserver.yaml

3 か所を編集します。まず command にフラグを追加します（アルファベット順で --authorization-mode の前です）。編集後の該当箇所：

    - --authentication-config=/etc/kubernetes/auth/anonymous.yaml
    - --authorization-mode=Node,RBAC

前節で --anonymous-auth=false を入れたまま復旧していない場合は、この行を削除してください。 排他制約により、両方あると起動しません。

次にコンテナの volumeMounts に 1 ブロック足します。既存のエントリ（k8s-certs など 4 つ）はそのまま残し、その並びに追加します。追加するブロック：

    - mountPath: /etc/kubernetes/auth
      name: auth-config
      readOnly: true

最後に Pod の volumes に 1 ブロック足します。こちらも既存のエントリを残したまま追加します。追加するブロック：

  - hostPath:
      path: /etc/kubernetes/auth
      type: DirectoryOrCreate
    name: auth-config

ステップ4：k8s-cp-01 で効き目を確認する#

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

# crictl ps | grep kube-apiserver

ATTEMPT が 0 の新しいコンテナに入れ替わっていることを確認してから、4 つのパスを測ります。

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

# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/livez
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/readyz
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/healthz
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/version

実行結果：

200
200
200
401

/version が 401 になり、/livez と /readyz は 200 のまま——これが本演習の合格条件です。RESTARTS が増えていないことも確認してください。

もし API Server が起動しない場合は、鉄則3 のとおりバックアップから戻してから差分を見直します。原因の大半は次の 3 つです。

• volumeMounts と volumes の name の綴り違い
• インデントの階層違い（volumes を containers の下に書いてしまう）
• --anonymous-auth=false の消し忘れ（排他制約）

ステップ5：k8s-cp-02 / k8s-cp-03 へ展開する#

k8s-cp-02（<cp-02 の IP> = 192.168.1.126）・k8s-cp-03（<cp-03 の IP> = 192.168.1.127）で、ステップ1 から ステップ4 を同じ順に繰り返します。curl の宛先 IP だけがその台のものに変わります。

ステップ6：クラスタ全体の健全性を確認する#

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

$ kubectl get nodes
$ kubectl get pod -n kube-system -o wide | grep apiserver
$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/

実行結果：

NAME        STATUS   ROLES           AGE   VERSION
k8s-cp-01   Ready    control-plane   26h   v1.36.2
k8s-cp-02   Ready    control-plane   23h   v1.36.2
k8s-cp-03   Ready    control-plane   23h   v1.36.2
k8s-wl-01   Ready    <none>          23h   v1.36.2
k8s-wl-02   Ready    <none>          23h   v1.36.2

kube-apiserver-k8s-cp-01   1/1   Running   0   4m22s   192.168.1.125   k8s-cp-01   <none>   <none>
kube-apiserver-k8s-cp-02   1/1   Running   0   2m2s    192.168.1.126   k8s-cp-02   <none>   <none>
kube-apiserver-k8s-cp-03   1/1   Running   0   48s     192.168.1.127   k8s-cp-03   <none>   <none>

200

AGE が 3 台とも短く、しかもバラバラであることに注目してください。1 台ずつ間を空けて適用した時間差が、そのまま AGE に現れています。 RESTARTS はいずれも 0 です。

k8s-ops からの kubectl が普段どおり動いていることも確認してください。kubectl はクライアント証明書を持っているので匿名ではありません。本演習の変更は、正規の資格情報を持つリクエストには何の影響も与えません。

到達点#

3 台すべてで匿名アクセスが /livez /readyz /healthz の 3 パスだけになり、クラスタは無停止のままです。HAProxy がどの台へ振り分けても、/version は 401 を返します。第4回で学んだ「HA では 3 台に揃えて初めて設定になる」が、ここでもそのまま効いています。

試験相当の粒度#

「指定された Control Plane の API Server に匿名アクセスの制限を設定せよ」という 1 問で 8〜10 分が目安です。試験で問われるのは 1 台分なので、本演習のステップ2〜4 だけを 1 セット打つ形になります。AuthenticationConfiguration の YAML は kubernetes.io/docs の Authenticating ページから取れるので、暗記より「どのページにあるか」を覚えるほうが有効です。時間を落とさない要点は、3 点セットを 1 回で書き切ることと、保存後に crictl ps で再起動を確かめてから次の設問へ移ることの 2 つです。

認可の関門 ——Node 認可と RBAC の二本立て#

② の関門です。ここは kubeadm が既定で締めているので、読み解きに徹します。

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

# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果：

    - --authorization-mode=Node,RBAC

kubeadm init が最初から書いている行です。2 つのモードが左から順に評価され、どちらかが許可すればリクエストは通ります（拒否は加算されません。第4回で扱った「RBAC は許可のみ」と同じ考え方です）。

なぜ Node 認可が必要なのか#

kubelet は Pod を起動するために、その Pod が参照する Secret・ConfigMap・PersistentVolume を読む必要があります。これを RBAC だけで表現しようとすると「全 Namespace の全 Secret を読める」という、極端に広い ClusterRole になってしまいます。ノードが 1 台侵害されただけでクラスタ全体の Secret が漏れる構図です。

Node 認可は、この判断を静的な権限表ではなく、その時点のスケジューリング結果に基づいて行います。「その kubelet のノードで動いている Pod が参照しているもの」だけに動的に絞るため、Pod が別ノードへ移れば参照できる範囲も変わります。RBAC では書けない種類の絞り方です。

これは第4回で扱った「最小権限」の考え方の延長にありますが、実現手段が RBAC ではない点が押さえどころです。CKS では「kubelet の権限をどう絞るか」という問いに対して、RBAC ではなく Node 認可を答えられる必要があります。

CIS でも確認できる#

この設定は kube-bench の 3 項目に対応します。

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

# kube-bench run --targets master --check 1.2.6,1.2.7,1.2.8

実行結果：

[INFO] 1 Control Plane Security Configuration
[INFO] 1.2 API Server
[PASS] 1.2.6 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)
[PASS] 1.2.7 Ensure that the --authorization-mode argument includes Node (Automated)
[PASS] 1.2.8 Ensure that the --authorization-mode argument includes RBAC (Automated)

== Summary master ==
3 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO

3 件とも既定で PASS します。第2回で「44 PASS」と数えたうちの 3 件は、自分では何もしていない PASSです。ベンチマークのスコアには、こうした「最初から満たしていた項目」が多く含まれます。

アンチパターン：AlwaysAllow#

--authorization-mode=AlwaysAllow は、認証を通ったすべてのリクエストを無条件に許可します。認可の関門が実質的に無くなるので、匿名アクセスが有効なままこれを設定すると、資格情報なしで何でもできるクラスタになります。

学習用に立てたクラスタや、古い手順書のまま構築された環境で見かける設定です。1.2.6 が一発で FAIL になるので、kube-bench を打てばすぐ分かります。監査を任されたクラスタでは、まずここを見てください。

逆に、モードの並びを RBAC,Node と書いても動作します。順序が結果を変えるのは「どちらが先に許可を返すか」だけで、最終的な可否は変わりません。順序より、両方が入っていることのほうが重要です。

Admission の関門 ——既定の 27 個と kubeadm が足す NodeRestriction#

③ の関門です。ここも kubeadm が既定で締めています。

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

# grep enable-admission-plugins /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果：

    - --enable-admission-plugins=NodeRestriction

この書き方には落とし穴がある#

この 1 行を素直に読むと「有効な Admission プラグインは NodeRestriction だけ」に見えます。そうではありません。 --enable-admission-plugins は「既定で有効なものに追加する」フラグです。

本書ラボ（v1.36.2）で既定有効だったのは次の 27 個です。

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority,
DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PodGroupProtection,
PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning,
ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, PodTopologyLabels,
PodGroupWorkloadExists, NodeDeclaredFeatureValidator, JobValidation, PodResizeValidator,
MutatingAdmissionPolicy, MutatingAdmissionWebhook, ValidatingAdmissionPolicy,
ValidatingAdmissionWebhook, ResourceQuota

その場で確かめる手順（試験でも使える）#

kube-apiserver --help の --enable-admission-plugins の説明に、括弧書きで既定一覧が載っています。ただし kubeadm クラスタでは kube-apiserver のバイナリがホストに無く、static Pod のコンテナの中にあります。そこで crictl exec で読みます。

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

# crictl ps | grep kube-apiserver
# crictl exec <kube-apiserver のコンテナ ID> kube-apiserver --help | grep -A 6 'enable-admission-plugins'

1 つ目のコマンドで表示された CONTAINER 列の ID を 2 つ目に渡します。この手順は Admission 以外にも効きます。本回では feature gate の確認にも同じ形を使いました。「フラグの既定値を知りたいときは crictl exec で --help」という手筋を覚えておくと、試験でドキュメントを開く回数が減ります。crictl の使い方そのものは kubernetes.io/docs にページがあるので、試験中に参照できます（後述の参照可否表を参照してください）。

一覧から読み取る 4 点#

EventRateLimit は「イベントの大量生成による API Server への負荷を制限する」プラグインです。有効化には --admission-control-config-file で設定ファイルを渡す必要があり、3 点セットの出番になります。同じ --admission-control-config-file は第14回の ImagePolicyWebhook でも使うので、そちらでまとめて扱います。

NodeRestriction が止めているもの#

NodeRestriction は、kubelet が自分の Node オブジェクトの一部フィールドを書き換えるのを拒否します。対象は node-restriction.kubernetes.io/ で始まるラベルや taints などです。

ここで層の違いが出ます。Node 認可は「他人のものを触らせない」、NodeRestriction は「自分のものでも触らせないフィールドがある」という線引きです。「自分の Node オブジェクトだから何をしてもよい」わけではない、というのが Admission 層の主張になります。

やってみよう③：越権を試して「どの関門が止めたか」を読む#

3 層モデルを 1 つのコマンド列で確認します。本回の概念部分の総仕上げです。

ステップ0：誰として認証されているかを確かめる#

第4回で使った auth whoami を、kubelet の kubeconfig で打ちます。

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf auth whoami

実行結果：

ATTRIBUTE                                           VALUE
Username                                            system:node:k8s-cp-01
Groups                                              [system:nodes system:authenticated]
Extra: authentication.kubernetes.io/credential-id   [X509SHA256=ccce317f7c550f98dd7dd8c5e0716596aed22aa46df4497c737647cc408d6a0c]

ここを確認してから先へ進んでください。 system:node:<ノード名> というユーザー名と system:nodes というグループが、Node 認可の判定対象そのものです。KUBECONFIG を渡し忘れると kubernetes-admin のまま打つことになり、以降のステップが全部成功してしまって演習になりません。

ステップ1：自ノードに任意ラベルを付ける#

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf label node k8s-cp-01 cks-test=self

実行結果：

node/k8s-cp-01 labeled

成功します。 kubelet は自分の Node オブジェクトに任意のラベルを付けられます。前節の最後で触れたとおり、普通のラベルによるノード選別は、kubelet の資格情報を持つ者に対しては防御になりません。

ステップ2：他ノードにラベルを付ける#

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf label node k8s-cp-02 cks-test=other

実行結果：

Error from server (Forbidden): nodes "k8s-cp-02" is forbidden: User "system:node:k8s-cp-01"
cannot get resource "nodes" in API group "" at the cluster scope:
node 'k8s-cp-01' cannot read 'k8s-cp-02', only its own Node object

拒否されました。メッセージの後半、only its own Node object が Node 認可の言い回しです。

ステップ3：他 Namespace の Secret を一覧する#

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf get secrets -n fanclub

実行結果：

Error from server (Forbidden): secrets is forbidden: User "system:node:k8s-cp-01"
cannot list resource "secrets" in API group "" in the namespace "fanclub": No Object name found

No Object name found は Node 認可の特徴的なメッセージです。Node 認可は「その kubelet の Pod が参照している、名前を指定された特定の Secret」しか許可しません。名前を指定しない list は、原理的に許可対象にならないため、こういう文面になります。

裏を返せば、そのノードで動いている Pod が使っている Secret は、名前を指定すれば読めます。ノードを取られた場合に守れるのは「そのノードに載っていない分」だけです。第9回の etcd 暗号化や、Secret をノードに置かない設計が意味を持つのはこのためです。

ステップ4：自ノードに node-restriction ラベルを付ける#

ステップ1 では自分の Node にラベルを付けられました。今度はプレフィックス付きのラベルで同じことを試します。

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf label node k8s-cp-01 node-restriction.kubernetes.io/owner=attacker

実行結果：

Error from server (Forbidden): nodes "k8s-cp-01" is forbidden:
is not allowed to modify labels: node-restriction.kubernetes.io/owner

対象は自分の Node です。 ステップ2 と違い「読めない」とは言われていません。認可は通っており、止めたのは Admission 層です。

ステップ5：後片付け#

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

# kubectl --kubeconfig=/etc/kubernetes/kubelet.conf label node k8s-cp-01 cks-test-

実行結果：

node/k8s-cp-01 unlabeled

ラベル名の末尾に - を付けると削除です。検証で付けたものはその場で外す——第4回の後片付けと同じ作法です。

読み解き ——同じ 403 でも止めた層が違う#

ステップ2・3・4 はすべて Error from server (Forbidden)、つまり HTTP 403 です。しかし止めた関門は同じではありません。

拒否メッセージが「主体の権限」を語っているか、「リクエストの中身」を語っているかで見分けます。前者が認可層、後者が Admission 層です。この読み分けは、Gatekeeper や ValidatingAdmissionPolicy を扱う第8回でも、そのまま使います。

試験相当の粒度#

「あるノードの kubelet 資格情報でできること・できないことを調べよ」という 1 問で 5〜8 分が目安です。時間を落とさない要点は 2 つです。--kubeconfig=/etc/kubernetes/kubelet.conf の綴りを覚えていることと、最初に auth whoami で誰になっているかを確かめること。この 2 つを飛ばすと、admin のまま検証して全部成功し、答えを間違えます。

第2回の宿題を回収する ——CIS 1.2.5 を恒久的に直す#

本回のもう 1 つの主題です。第2回で保留した 1.2.5（--kubelet-certificate-authority） を、今度は壊さずに PASS にします。

第2回で何が起きたか#

第2回では、1.2.5 の Remediation に従って --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt を足しました。API Server は正常に起動し、/healthz も ok を返しました。ところが kubectl logs と kubectl exec が x509 エラーで壊れ、しかも HA なので「たまに失敗する」という形で現れました。最終的にバックアップから戻し、恒久対応を本回へ送っています。

CIS の主張自体は正しいという点を、もう一度確認しておきます。既定では API Server は kubelet のサーバ証明書を検証していません。中間者攻撃で kubelet になりすまされると、kubectl exec の内容や Pod のログが盗まれます（成立するには、Control Plane からノードの 10250 へ向かう経路に割り込める位置を取られている必要があります。ノード間ネットワークが信頼できない環境ほど効いてくる話です）。検証を有効にすべきだ、という主張には理があります。

なぜ壊れたのか#

kubelet は 10250 番ポートで HTTPS を待ち受けています。API Server が kubectl logs を中継するとき、この 10250 へ接続します。そこで提示される kubelet のサーバ証明書が自己署名である、というのが原因です。

証明書の中身は、第2回 やってみよう③ と同じやり方で確認できます（openssl は k8s-ops にも Control Plane Node にも入っていないため、curl -kv の出力を読みます）。

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

# curl -kv --noproxy '*' https://192.168.1.125:10250/healthz 2>&1 | grep -E 'subject:|issuer:|verify result'

実行結果：

* subject: CN=k8s-cp-01@1784976573
* issuer: CN=k8s-cp-01-ca@1784976573
* SSL certificate verify result: self-signed certificate in certificate chain (19)

読み取れることは 3 つです。

• issuer が CN=k8s-cp-01-ca@...——kubelet が自分で作った CA が発行元になっている
• したがってクラスタ CA（CN=kubernetes）とはまったく無関係である
• 末尾の数字は生成時刻（UNIX 時間）なので、読者の環境では別の値になる

--kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt は「クラスタ CA で検証しろ」という指示です。無関係な CA が発行した証明書は当然通りません。フラグが悪いのではなく、kubelet 側の証明書運用が整っていないのが原因です。

直し方 ——serverTLSBootstrap#

kubelet に「サーバ証明書も自分で作らず、クラスタ CA に発行してもらえ」と指示する設定が serverTLSBootstrap: true です。これを入れると、kubelet は起動時に CSR（証明書署名要求）を API Server へ提出します。

承認されると、クラスタ CA が署名したサーバ証明書が払い出され、kubelet はそれを 10250 で提示するようになります。発行元がクラスタ CA になるので、--kubelet-certificate-authority による検証が通ります。

この CSR は自動承認されない#

kubeadm クラスタには CSR の自動承認が仕込まれていますが、対象は 1 種類だけです。

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

$ kubectl get clusterrolebinding | grep autoapprove

実行結果：

kubeadm:node-autoapprove-certificate-rotation   ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient

参照されている ClusterRole の名前の末尾に注目してください。selfnodeclient——つまりクライアント証明書のローテーションだけが自動承認されます。サーバ証明書に対応する selfnodeserver の ClusterRole は、そもそもクラスタに存在しません。

したがって kubernetes.io/kubelet-serving の CSR は、必ず人間が承認します。

なぜ自動承認しない設計なのか#

サーバ証明書には、ノードが自己申告した IP とホスト名が SAN として入ります。これを無条件に自動承認すると、乗っ取られたノードが他ノードの IP を名乗る証明書を正規に手に入れられます。その証明書があれば、API Server の kubectl exec 中継を横取りできる可能性が生じます。

やってみよう③ で確認したとおり、kubelet の資格情報は「自分の Node は触れる」立場にあります。自己申告の内容を検証せずに署名すると、その立場が他ノードのなりすましにまで広がります。 だから人間が確認する設計になっています。

運用上の注意 ——承認は 1 回で終わらない#

アップグレードとの順序制約#

本回固有の落とし穴です。serverTLSBootstrap: true を /var/lib/kubelet/config.yaml に直接書くだけでは足りません。

この設定の SSOT（単一の真実）は、kube-system Namespace の kubelet-config ConfigMap です。kubeadm upgrade node は、ローカルの /var/lib/kubelet/config.yaml を ConfigMap の内容で丸ごと上書きします。dry-run で確認できます。

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

# kubeadm upgrade node phase kubelet-config --dry-run

実行結果（抜粋）：

[dryrun] Would back up kubelet config file to /etc/kubernetes/tmp/.../config.yaml
[dryrun] Would write file "/var/lib/kubelet/config.yaml" with content:
apiVersion: kubelet.config.k8s.io/v1beta1

Would write file——書き換えるのではなく、書き出すと言っています。ローカルファイルだけを編集していると、次の順で事故が起きます。

1. ローカルの /var/lib/kubelet/config.yaml にだけ serverTLSBootstrap: true を書く
2. CSR を承認し、kubectl logs が動くようになる。API Server に --kubelet-certificate-authority を入れる
3. 後日 kubeadm upgrade node を実行する
4. ローカルファイルが ConfigMap の内容で上書きされ、serverTLSBootstrap が消える
5. kubelet が自己署名証明書に戻る。API Server 側のフラグは残っているので、kubectl logs が再び壊れる

ConfigMap を先に直してください。 次の演習ではこの順序を守ります。第4回の最後で「手で締めた設定は helm upgrade や kubeadm upgrade で巻き戻る。恒久対応は生成する側に書く」と書いたのと同じ構図です。今回の「生成する側」が kubelet-config ConfigMap にあたります。

やってみよう④：kubelet サービング証明書をクラスタ CA 署名へ切り替える#

ステップ1：kubelet-config ConfigMap を直す（先にこちら）#

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

$ kubectl get cm kubelet-config -n kube-system -o yaml > ~/kubelet-config.bak-05.yaml
$ kubectl edit cm kubelet-config -n kube-system

編集箇所（前後の数行だけを抜き出しています。+ の行が追加分です）：

  kubelet: |
    apiVersion: kubelet.config.k8s.io/v1beta1
    rotateCertificates: true
+   serverTLSBootstrap: true
    staticPodPath: /etc/kubernetes/manifests

実際に打ち込むのは serverTLSBootstrap: true の 1 行だけで、行頭の + は差分を示す記号です。保存したら反映を確認します。

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

$ kubectl get cm kubelet-config -n kube-system -o yaml | grep serverTLSBootstrap

実行結果：

    serverTLSBootstrap: true

ステップ2：5 ノードのローカル設定にも同じ行を足す#

ConfigMap を直しても、kubelet が今読んでいるのはローカルファイルです。5 ノードすべてで同じ行を足し、kubelet を再起動します。

実行コマンド（k8s-cp-01 上・root / 残る 4 ノードでも同じ）：

# cp /var/lib/kubelet/config.yaml /root/kubelet-config.yaml.bak-05
# echo "serverTLSBootstrap: true" >> /var/lib/kubelet/config.yaml
# systemctl restart kubelet

>> による追記なのでファイル末尾に入ります。KubeletConfiguration はトップレベルのキーの並びなので、末尾追記で問題ありません（ConfigMap 側と違い、埋め込み文字列ではないためインデントは不要です）。

再起動後、kubelet が起動していることを確認してから次のノードへ進んでください。

実行コマンド（各ノード上・root）：

# systemctl is-active kubelet

実行結果：

active

ステップ3：CSR が Pending で出ていることを確認する#

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

$ kubectl get csr

実行結果：

NAME        AGE   SIGNERNAME                      REQUESTOR               REQUESTEDDURATION   CONDITION
csr-68sh9   50s   kubernetes.io/kubelet-serving   system:node:k8s-cp-02   <none>              Pending
csr-6r2pv   54s   kubernetes.io/kubelet-serving   system:node:k8s-cp-01   <none>              Pending
csr-6sqhv   43s   kubernetes.io/kubelet-serving   system:node:k8s-cp-03   <none>              Pending
csr-b8sbc   31s   kubernetes.io/kubelet-serving   system:node:k8s-wl-02   <none>              Pending
csr-vv28z   37s   kubernetes.io/kubelet-serving   system:node:k8s-wl-01   <none>              Pending

NAME はランダムなので、読者の環境では別の文字列になります。見るべき列は SIGNERNAME と CONDITION の 2 つです。Pending が 5 件（5 ノード分）出ていることを確認してください。

ステップ4：中身を確認してから承認する#

前節で説明したとおり、この承認は「自己申告の内容を人間が確かめる」工程です。確かめずに承認する癖を付けないでください。

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

$ kubectl get csr <CSR 名> -o jsonpath='{.spec.username}{"\n"}'
$ kubectl certificate approve <CSR 名>

spec.username が system:node:<ノード名> になっていて、それが自分の管理下のノード名と一致することを確認します。5 件すべてを 1 件ずつ確認したうえで、まとめて承認する形も使えます。

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

$ kubectl get csr --field-selector spec.signerName=kubernetes.io/kubelet-serving -o name | xargs kubectl certificate approve

実行結果：

certificatesigningrequest.certificates.k8s.io/csr-68sh9 approved
certificatesigningrequest.certificates.k8s.io/csr-6r2pv approved
certificatesigningrequest.certificates.k8s.io/csr-6sqhv approved
certificatesigningrequest.certificates.k8s.io/csr-b8sbc approved
certificatesigningrequest.certificates.k8s.io/csr-vv28z approved

--field-selector で kubelet-serving のものだけに絞っているのが要点です。絞らずに全 CSR を承認すると、意図しない証明書まで発行してしまいます。 承認後の状態を確認します。

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

$ kubectl get csr --field-selector spec.signerName=kubernetes.io/kubelet-serving

実行結果：

NAME        AGE   SIGNERNAME                      REQUESTOR               REQUESTEDDURATION   CONDITION
csr-68sh9   57s   kubernetes.io/kubelet-serving   system:node:k8s-cp-02   <none>              Approved,Issued
csr-6r2pv   61s   kubernetes.io/kubelet-serving   system:node:k8s-cp-01   <none>              Approved,Issued
csr-6sqhv   50s   kubernetes.io/kubelet-serving   system:node:k8s-cp-03   <none>              Approved,Issued
csr-b8sbc   38s   kubernetes.io/kubelet-serving   system:node:k8s-wl-02   <none>              Approved,Issued
csr-vv28z   44s   kubernetes.io/kubelet-serving   system:node:k8s-wl-01   <none>              Approved,Issued

CONDITION が 5 件とも Approved,Issued になりました。Approved だけで Issued が付いていない場合は、署名が済んでいません——その状態では証明書はまだ差し替わっていないので、少し待ってから見直してください。

Approved,Issued の 2 語が並んでいれば完了です。Approved だけで Issued が付かない場合は、署名側（kube-controller-manager）で問題が起きています。

ステップ5：証明書が差し替わったことを確認する#

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

# ls -l /var/lib/kubelet/pki/

実行結果（kubelet-server 関連の行の抜粋）：

-rw-------. 1 root root 1151  7月 26 21:53 kubelet-server-2026-07-26-21-53-02.pem
lrwxrwxrwx. 1 root root   59  7月 26 21:53 kubelet-server-current.pem -> /var/lib/kubelet/pki/kubelet-server-2026-07-26-21-53-02.pem

日時入りの実体ファイルと、それを指すシンボリックリンク kubelet-server-current.pem が作られます。ファイル名の日時は読者の環境では別の値になります。次回のローテーション時には新しい実体ファイルができ、リンクの向き先が変わります。

提示される証明書そのものも確認します。第2回と同じやり方です。

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

# curl -kv --noproxy '*' https://192.168.1.125:10250/healthz 2>&1 | grep -E 'subject:|issuer:'

実行結果：

* subject: O=system:nodes; CN=system:node:k8s-cp-01
* issuer: CN=kubernetes

issuer が CN=kubernetes になりました。 クラスタ CA が署名した証明書です。subject も CN=k8s-cp-01@<数字> という自己流の名前ではなく、O=system:nodes / CN=system:node:k8s-cp-01 という Kubernetes の識別子の形になっています。証明書だけを見て「このノードは誰か」が分かる状態です。

5 ノードすべてで同じ確認をしてください。ここで 1 台でも自己署名のままなら、次のステップで kubectl logs が壊れます。

ステップ6：k8s-cp-01 の API Server にフラグを足す#

ここでようやく、第2回で壊れたフラグを入れ直します。

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

# cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak-05b
# vi /etc/kubernetes/manifests/kube-apiserver.yaml

挿入位置は --kubelet-client-certificate の直前です。編集後の該当箇所：

    - --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key

保存すると kubelet が static Pod を作り直します（鉄則2）。次のステップへ進む前に、再起動が終わったことを確認してください。 再起動中の k8s-cp-01 は 6443 番に応答しないので、そのまま ステップ7 を打つと接続エラーになり、「フラグを入れたから壊れた」と誤解します。

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

# crictl ps | grep kube-apiserver
# curl -s -o /dev/null -w '%{http_code}\n' -k --noproxy '*' https://192.168.1.125:6443/livez

ATTEMPT が 0 の新しいコンテナに入れ替わり、/livez が 200 を返してから次へ進みます。本書ラボではおよそ 1 分でした。ATTEMPT が増えていく場合は起動に失敗しているので、/root/kube-apiserver.yaml.bak-05b から戻して差分を見直してください。

ステップ7：第2回で壊れた 3 つを全部試す#

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

$ kubectl --server=https://192.168.1.125:6443 --insecure-skip-tls-verify logs -n fanclub -l app=fanclub-frontend --tail=3
$ kubectl --server=https://192.168.1.125:6443 --insecure-skip-tls-verify exec -n fanclub deploy/fanclub-frontend -- echo EXEC_OK
$ kubectl --server=https://192.168.1.125:6443 --insecure-skip-tls-verify top nodes

実行結果：

10.244.119.164 - - [26/Jul/2026:12:31:10 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "192.168.1.129"
10.244.119.164 - - [26/Jul/2026:12:33:53 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "192.168.1.129"
10.244.119.164 - - [26/Jul/2026:12:49:42 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "192.168.1.129"
2026/07/26 12:27:52 [notice] 1#1: start worker process 33
10.244.119.164 - - [26/Jul/2026:12:33:53 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "192.168.1.129"
10.244.119.164 - - [26/Jul/2026:12:36:25 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "192.168.1.129"

EXEC_OK

NAME        CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
k8s-cp-01   106m         5%       1956Mi          55%
k8s-cp-02   135m         6%       2213Mi          62%
k8s-cp-03   144m         7%       2208Mi          62%
k8s-wl-01   176m         4%       5079Mi          67%
k8s-wl-02   141m         3%       3854Mi          50%

-l app=fanclub-frontend は 2 つの Pod にまたがるので、ログが Pod 単位で続けて出ます（時刻が前後して見えるのはこのためです）。第2回で x509 エラーになった 3 つが、すべて通りました。

--insecure-skip-tls-verify を付けているのは、admin.conf の server: が k8s-lb を指しているためです（--server で IP に上書きすると、証明書の SAN との突き合わせで警告が出る場合があります）。ここで確かめたいのは API Server と kubelet の間の TLS であり、kubectl と API Server の間の TLS ではありません。

top nodes も試すのは、metrics-server と同じ経路（API Server から kubelet の 10250）を使うためです。3 つとも成功すれば、第2回で壊れたものはすべて直っています。

ステップ8：k8s-cp-02 / k8s-cp-03 にも同じフラグを足す#

ステップ6 と同じ編集を、1 台ずつ・確認してから次への原則で行います。編集後は各台で crictl ps と --server 名指しの確認を行ってください。

ステップ8-b：名指しを外して 6 回連続で成功することを確認する#

3 台に入れ終えたら、--server を外して同じコマンドを繰り返します。第2回が読者に課したのと同じ確認形式です。

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

$ for i in 1 2 3 4 5 6; do kubectl logs -n fanclub -l app=fanclub-frontend --tail=1 > /dev/null && echo "OK $i" || echo "NG $i"; done

実行結果：

OK 1
OK 2
OK 3
OK 4
OK 5
OK 6

HAProxy が 3 台へ振り分けるので、6 回連続の成功が「3 台すべてで正しく動いている」ことの実用的な証拠になります。どれか 1 台でも取りこぼしがあると、ここで断続的に NG が混じります。混じったら止めて、どの台の設定が抜けているかを探してください。

ステップ9：kube-bench で 1.2.5 が PASS になったことを確認する#

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

# export KUBECONFIG=/etc/kubernetes/admin.conf
# kube-bench run --targets master --check 1.2.5

実行結果：

[INFO] 1 Control Plane Security Configuration
[INFO] 1.2 API Server
[PASS] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)

== Summary master ==
1 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO

全体のスコアも取り直します。

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

# kube-bench run --targets master | tail -11

実行結果：

== Summary master ==
45 checks PASS
4 checks FAIL
11 checks WARN
0 checks INFO

== Summary total ==
45 checks PASS
4 checks FAIL
11 checks WARN
0 checks INFO

第1回から本回までの推移は次のとおりです。

残る FAIL 4 件はすべて監査ログ（1.2.16〜1.2.19）で、第16回で回収します。 WARN 11 件が動いていない点にも注目してください。本回で匿名アクセスを締めても、--anonymous-auth=false という文字列を書かない限り 1.2.1 は WARN のままです。スコアの改善と実際の堅牢化は、別々に評価する必要があります。

試験相当の粒度#

「Pending になっている kubelet-serving の CSR を承認せよ」という 1 問で 5〜8 分が目安です。試験で問われるのは本演習のステップ3〜4 だけで、設定の投入や API Server 側のフラグまでは求められないことが多くなります。時間を落とさない要点は、kubectl get csr の SIGNERNAME 列を見て対象を絞ることと、kubectl certificate approve の綴り（approve であって approval ではありません）です。拒否は kubectl certificate deny です。

やってみよう⑤：脆弱性を塞ぐ ——v1.36.2 から v1.36.3 へ#

CKS D2 の「Upgrade Kubernetes to avoid vulnerabilities」に対応する節です。

アップグレードを「運用」ではなく「防御」として打つ#

Kubernetes のパッチリリースには、公表済み脆弱性（CVE）の修正が入ります。古いパッチに留まることは、攻撃者が CVE 番号で検索できる穴を開けたままにしておくのと同じです。

本回の前半で確認したことを思い出してください。匿名アクセスが有効なクラスタでは /version からバージョンが読めました。 攻撃者から見れば「このクラスタは v1.36.2 だ」という情報は、どの CVE を試すかを決める材料です。匿名を締めることと、パッチを当てることは、同じリスクへの 2 方向からの対処です。

実務では「動いているものは触らない」という判断が働きがちですが、セキュリティの観点では「触らないこと」がリスクの蓄積になります。パッチ適用を定期作業として組み込めるかどうかが、運用設計の分かれ目になります。

バージョンスキュー ——順序を決めているのは 1 つの原則#

この表は暗記事項ですが、丸暗記する必要はありません。「API Server が最も新しくなければならない」という 1 点から、ほぼすべてが導けます。API Server が最新であるべきなら、上げる順序は API Server が先——つまり Control Plane が先で Workload Node が後になります。

$ kubectl version

パッチ更新とマイナー更新の違い#

第2巻第6回で扱ったのは右の列でした。本回は左の列です。 リポジトリ URL を触らない分だけ手数は少なくなりますが、1 ノードあたりの手順そのものは同じです。

なお、v1.37 のリポジトリは本記事の執筆時点で存在しません（アクセスすると 403 が返ります）。v1.36 系で到達できる最新は v1.36.3 です。「1 マイナー上げる」ができないときにパッチ更新を選ぶ——という判断も、実務ではよくあります。

ステップ1：計画を見る#

kubeadm upgrade plan は、kubeadm 自体を上げる前に打てます。何がどこまで上がるのかを先に把握してください。

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

# kubeadm upgrade plan

実行結果（要点の抜粋）：

[upgrade/versions] Cluster version: 1.36.2
[upgrade/versions] kubeadm version: v1.36.2
[upgrade/versions] Target version: v1.36.3
[upgrade/versions] Latest version in the v1.36 series: v1.36.3

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   NODE        CURRENT   TARGET
kubelet     k8s-cp-01   v1.36.2   v1.36.3

Upgrade to the latest version in the v1.36 series:
COMPONENT                 NODE        CURRENT   TARGET
kube-apiserver            k8s-cp-01   v1.36.2   v1.36.3
kube-controller-manager   k8s-cp-01   v1.36.2   v1.36.3
kube-scheduler            k8s-cp-01   v1.36.2   v1.36.3
kube-proxy                            1.36.2    v1.36.3
CoreDNS                               v1.14.2   v1.14.2
etcd                      k8s-cp-01   3.6.8-0   3.6.8-0

You can now apply the upgrade by executing the following command:

	kubeadm upgrade apply v1.36.3

Note: Before you can perform this upgrade, you have to update kubeadm to v1.36.3.

実際の出力では kubelet の行が 5 ノード分並びます。読み取るのは 3 点です。

• Target version: v1.36.3——到達先が確定した
• CoreDNS と etcd の CURRENT と TARGET が同じ——パッチ更新なので据え置き。マイナー更新では、ここが上がることが多い
• kubelet は手動——kubeadm upgrade apply は Control Plane のコンポーネントを入れ替えるだけで、kubelet のパッケージは自分で上げる

最後の Note も重要です。kubeadm 自体を先に v1.36.3 へ上げないと、apply は実行できません。

1 ノードあたりの手順は 5 段階#

この 5 段階を、k8s-cp-01 → k8s-cp-02 → k8s-cp-03 → k8s-wl-01 → k8s-wl-02 の順に 1 台ずつ繰り返します。 k8s-cp-01 とそれ以外の違いは、③ が kubeadm upgrade apply v1.36.3 になるか kubeadm upgrade node になるかの 1 点だけです。

①〜⑤ は 1 ノードの中で閉じます。次のノードへ移る前に、必ず ⑤ の貼り直しまで終えてください。 ① を 5 台分まとめて外してから ② へ進む、という進め方はしないでください（本節末尾の本番ガードレール③ で理由を書きます）。

dnf の出力は日本語ロケールだと和文になります。本文は LC_ALL=C を前置した英語表示で統一します（第2回の sha256sum --check と同じ方針です）。

④ の drain について、Control Plane Node ではほとんど何も退避しません。node-role.kubernetes.io/control-plane:NoSchedule の taint があるため、載っているのは DaemonSet と static Pod が中心だからです（--ignore-daemonsets は必要です）。退避先の余裕を気にするのは Workload Node の 2 台だけで、その手順は後述します。

パッケージ名に付けるバージョン文字列は、リポジトリの実物を見て確定します。versionlock が効いていると通常の list では候補が見えないので、プラグインを一時的に無効化して問い合わせます。

実行コマンド（当該ノード上・root）：

# dnf --disableplugin=versionlock list --showduplicates kubeadm kubelet kubectl | grep 1.36.3

実行結果（x86_64 の行のみ抜粋）：

kubeadm.x86_64                   1.36.3-150500.1.1                   kubernetes
kubectl.x86_64                   1.36.3-150500.1.1                   kubernetes
kubelet.x86_64                   1.36.3-150500.1.1                   kubernetes

1.36.3-150500.1.1 の後半（-150500.1.1）はパッケージのリリース番号で、Kubernetes のバージョンとは別物です。読者の環境では別の値になることがあるので、本文の値を写すのではなく、必ず自分の環境で確認した値を使ってください。

# LC_ALL=C dnf versionlock list

Last metadata expiration check: 0:01:07 ago on Sun Jul 26 21:59:19 2026.
kubeadm-0:1.36.2-150500.2.1.*
kubelet-0:1.36.2-150500.2.1.*
kubectl-0:1.36.2-150500.2.1.*

# LC_ALL=C dnf versionlock delete kubeadm kubelet kubectl

Deleting versionlock for: kubeadm-0:1.36.2-150500.2.1.*
Deleting versionlock for: kubelet-0:1.36.2-150500.2.1.*
Deleting versionlock for: kubectl-0:1.36.2-150500.2.1.*

バージョン指定について、第2巻から引き継いだ原則を再掲します。リポジトリ URL の v1.36 はマイナーまでの指定なので、これだけではパッチが固定されません。dnf install でパッチまで明示し、kubeadm upgrade apply にも v1.36.3 と明示します。両方に書いてはじめてバージョンが決まります。

ステップ1-b：手動で足したフラグを kubeadm-config へ移す#

# LC_ALL=C dnf versionlock delete kubeadm kubelet kubectl
# LC_ALL=C dnf install -y kubeadm-1.36.3-150500.1.1
# kubeadm version -o short

v1.36.3

error: error execution phase preflight: the version argument is invalid due to these errors:

	- Specified version to upgrade to "v1.36.3" is higher than the kubeadm version "v1.36.2". Upgrade kubeadm first using the tool you used to install kubeadm

本当にそうなるのかを、実行する前に確かめます。kubeadm upgrade apply には --dry-run があり、「どんなファイルを書こうとしているか」を実行せずに全文表示できます。

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

# kubeadm upgrade apply v1.36.3 --dry-run 2>&1 | grep -A 40 'Would write file "/etc/kubernetes/manifests/kube-apiserver.yaml"'

実行結果（command の部分の抜粋）：

[dryrun] Would write file "/etc/kubernetes/manifests/kube-apiserver.yaml" with content:
apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.125
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key

本回で足した --authentication-config も --kubelet-certificate-authority も、第2回の --profiling=false も、第4回の --service-account-max-token-expiration=24h も、1 つも入っていません。 volumeMounts と volumes の auth-config も消えています。このまま upgrade apply を実行すれば、第2回から積み上げた設定がすべて失われます。

正しい置き場所は kubeadm-config ConfigMap の ClusterConfiguration です。現状を見ます。

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

$ kubectl get cm kubeadm-config -n kube-system -o jsonpath='{.data.ClusterConfiguration}'

実行結果（全量）：

apiServer: {}
apiVersion: kubeadm.k8s.io/v1beta4
caCertificateValidityPeriod: 87600h0m0s
certificateValidityPeriod: 8760h0m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: k8s-lb:6443
controllerManager: {}
dns: {}
encryptionAlgorithm: RSA-2048
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.k8s.io
kind: ClusterConfiguration
kubernetesVersion: v1.36.2
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
proxy: {}
scheduler: {}

apiServer: {} ——空です。 手で足したフラグは、kubeadm から見れば「存在しない設定」でした。ここに extraArgs（フラグ）と extraVolumes（3 点セットの ②③ に相当）を書きます。

空なのは apiServer だけではありません。 controllerManager: {} と scheduler: {} も同じく空です。第2回で --profiling=false を入れたのは 3 コンポーネント（apiserver / controller-manager / scheduler）なので、この 2 つも一緒に移さないと、アップグレードで controller-manager と scheduler のフラグだけが消えます——kubeadm はこの 3 つのマニフェストをすべて作り直すからです。

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

$ kubectl get cm kubeadm-config -n kube-system -o yaml > ~/kubeadm-config.bak-05.yaml
$ kubectl edit cm kubeadm-config -n kube-system

apiServer: {} の行を、次の内容に置き換えます（全量）。

apiServer:
  extraArgs:
  - name: authentication-config
    value: /etc/kubernetes/auth/anonymous.yaml
  - name: kubelet-certificate-authority
    value: /etc/kubernetes/pki/ca.crt
  - name: profiling
    value: "false"
  - name: service-account-extend-token-expiration
    value: "false"
  - name: service-account-max-token-expiration
    value: 24h
  extraVolumes:
  - name: auth-config
    hostPath: /etc/kubernetes/auth
    mountPath: /etc/kubernetes/auth
    readOnly: true
    pathType: DirectoryOrCreate

あわせて controllerManager: {} と scheduler: {} の 2 行も置き換えます（全量）。

controllerManager:
  extraArgs:
  - name: profiling
    value: "false"
scheduler:
  extraArgs:
  - name: profiling
    value: "false"

# ls -l /etc/kubernetes/auth/

合計 4
-rw-------. 1 root root 168  7月 26 21:44 anonymous.yaml

ここには 第2回・第4回で足したフラグも一緒に書いています。手で足したものはすべて対象だからです。--profiling=false は第2回で k8s-cp-01 にだけ入れて、残り 2 台は読者に委ねていました。これを ClusterConfiguration に書くと、アップグレードのタイミングで 3 台に自動で揃います。

編集したら、もう一度 --dry-run で確かめます。確認せずに本番の apply を打たないでください。

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

# kubeadm upgrade apply v1.36.3 --dry-run 2>&1 | grep -A 130 'Would write file "/etc/kubernetes/manifests/kube-apiserver.yaml"' | grep -E 'authentication-config|kubelet-certificate-authority|profiling|service-account-max|auth-config|kubernetes/auth|image:'

実行結果：

    - --authentication-config=/etc/kubernetes/auth/anonymous.yaml
    - --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt
    - --profiling=false
    - --service-account-extend-token-expiration=false
    - --service-account-max-token-expiration=24h
    image: registry.k8s.io/kube-apiserver:v1.36.3
    - mountPath: /etc/kubernetes/auth
      name: auth-config
      path: /etc/kubernetes/auth
    name: auth-config

5 つのフラグと 3 点セットのマウントが、新しいマニフェスト（イメージは v1.36.3）に載りました。 extraArgs で足したフラグは kubeadm 既定のフラグ群の後ろに追加されるため、アルファベット順にはなりません。これは正常です。

ステップ2〜6：5 台を順に上げる#

上の 5 段階を、k8s-cp-01 → k8s-cp-02 → k8s-cp-03 → k8s-wl-01 → k8s-wl-02 の順に実施します。各ノードの完了後に、そのノードが Ready かつ新バージョンになったことを確認してから次へ進んでください。

k8s-cp-01 については、ステップ1-b で ① と ② を済ませてあります。③ から始めてください。 k8s-cp-02 以降は ① から順に打ちます。

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

$ kubectl get nodes

VERSION 列が対象ノードだけ v1.36.3 になり、他は v1.36.2 のまま——という混在状態が正常です。混在に耐えられるのは、前述のスキュー許容範囲に収まっているからです。

1 台目（k8s-cp-01）の ③ の実出力は次のとおりです。

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

# kubeadm upgrade apply v1.36.3

実行結果：

[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moving new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backing up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2026-07-26-22-03-57/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This can take up to 5m0s
[apiclient] Found 3 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moving new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backing up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2026-07-26-22-03-57/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This can take up to 5m0s
[apiclient] Found 3 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upgrade/control-plane] The control plane instance for this node was successfully upgraded!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upgrade/kubeconfig] The kubeconfig files for this node were successfully upgraded!
[upgrade] Backing up kubelet config file to /etc/kubernetes/tmp/kubeadm-kubelet-config-2026-07-26-22-05-19/config.yaml
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade/kubelet-config] The kubelet configuration for this node was successfully upgraded!
[upgrade/bootstrap-token] Configuring bootstrap token and cluster-info RBAC rules
[upgrade/addon] Skipping upgrade of addons because control plane instances [k8s-cp-02 k8s-cp-03] have not been upgraded

[upgrade] SUCCESS! A control plane node of your cluster was upgraded to "v1.36.3".

[upgrade] Now please proceed with upgrading the rest of the nodes by following the right order.

本書ラボでは 約 2 分で完了しました。読み取っておきたい行が 4 つあります。

• Moving new manifest to ... and backing up old manifest to /etc/kubernetes/tmp/kubeadm-backup-manifests-<日時>/——kubeadm は古いマニフェストを自分で退避します。ステップ1-b で確認したとおり内容は作り直されるので、この退避先が「元の姿」を残す唯一の場所になります
• [upload-config] Storing the configuration used in ConfigMap "kubeadm-config"——ClusterConfiguration の kubernetesVersion が v1.36.3 へ書き戻されます
• [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"——ここで kubelet 設定も ConfigMap から書き直されます。やってみよう④ のステップ1 が効くのはこの瞬間です
• [upgrade/addon] Skipping upgrade of addons because control plane instances [k8s-cp-02 k8s-cp-03] have not been upgraded——CoreDNS と kube-proxy の更新は最後の Control Plane を上げるまで保留されます

2 台目以降（k8s-cp-02 / k8s-cp-03 / k8s-wl-01 / k8s-wl-02）は node です。バージョン指定は要りません（クラスタの目標バージョンを参照するためです）。

実行コマンド（当該ノード上・root）：

# kubeadm upgrade node

実行結果：

[apiclient] Found 3 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moving new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backing up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2026-07-26-22-06-35/kube-controller-manager.yaml"
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upgrade/control-plane] The control plane instance for this node was successfully upgraded!
[upgrade/kubeconfig] The kubeconfig files for this node were successfully upgraded!
[upgrade] Backing up kubelet config file to /etc/kubernetes/tmp/kubeadm-kubelet-config-2026-07-26-22-08-12/config.yaml
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade/kubelet-config] The kubelet configuration for this node was successfully upgraded!
[upgrade/addon] Skipping upgrade of addons because control plane instances [k8s-cp-03] have not been upgraded

最後の Control Plane（k8s-cp-03）だけは末尾が変わります。 保留されていたアドオンがここで適用されるためです。

実行結果（k8s-cp-03 の末尾）：

[upgrade/kubelet-config] The kubelet configuration for this node was successfully upgraded!
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Workload Node（k8s-wl-01 / k8s-wl-02）では、Control Plane 向けのフェーズが丸ごと飛ばされます。

実行結果（k8s-wl-01）：

[upgrade/preflight] Running pre-flight checks
[upgrade/preflight] Skipping prepull. Not a control plane node.
[upgrade/control-plane] Skipping phase. Not a control plane node.
[upgrade/kubeconfig] Skipping phase. Not a control plane node.
[upgrade] Backing up kubelet config file to /etc/kubernetes/tmp/kubeadm-kubelet-config-2026-07-26-22-13-06/config.yaml
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade/kubelet-config] The kubelet configuration for this node was successfully upgraded!
[upgrade/addon] Skipping the addon/coredns phase. Not a control plane node.
[upgrade/addon] Skipping the addon/kube-proxy phase. Not a control plane node.

Workload Node で kubeadm upgrade node が実際にやることは、kubelet 設定の書き直しだけです。 それでもこのコマンドが要るのは、/var/lib/kubelet/config.yaml を新しいバージョンの形式へ合わせるためです。

Workload Node を drain するときの手順#

本書ラボの Workload Node は 2 台しかありません。片方を drain すると fanclub 一式がもう片方に集中します。 次の順で判断してください。

1. kubectl get pod -A -o wide | grep -E 'fanclub|longhorn' で fanclub-db-0 がどちらのノードに載っているかを先に確認する
2. db-0 が載っていない側のノードから先に drain する
3. kubectl drain <node> --ignore-daemonsets --delete-emptydir-data を使う（--delete-emptydir-data が無いと emptyDir を持つ Pod で止まります）
4. drain が進まないときは --force を打たずに原因を調べる。 kubectl get pdb -A を見てください（Longhorn の instance-manager は PodDisruptionBudget を持つため、evict できずに待ち続けることがあります）
5. uncordon したあと、fanclub-backend が 2/2 に戻ってから次のノードへ進む

本書ラボで実際に起きたことを載せておきます。PDB による待ちは確かに発生しますが、待っていれば解消します。

実行結果（k8s-wl-01 の drain・抜粋）：

evicting pod longhorn-system/instance-manager-fab969fd0e41cf59df06951809055bda
error when evicting pods/"instance-manager-fab969fd0e41cf59df06951809055bda" -n "longhorn-system" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod longhorn-system/instance-manager-fab969fd0e41cf59df06951809055bda
error when evicting pods/"instance-manager-fab969fd0e41cf59df06951809055bda" -n "longhorn-system" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod longhorn-system/instance-manager-fab969fd0e41cf59df06951809055bda
pod/instance-manager-fab969fd0e41cf59df06951809055bda evicted
pod/fanclub-backend-788b7bbd7c-tfzv8 evicted
pod/fanclub-backend-788b7bbd7c-mmhrr evicted
node/k8s-wl-01 drained

Cannot evict pod as it would violate the pod's disruption budget. が 5 秒おきに数回繰り返されたあと、evict が通って drain が完了しました。PDB の状態は次で確認できます。

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

$ kubectl get pdb -A

実行結果：

NAMESPACE         NAME                                                MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
kube-system       calico-kube-controllers                             N/A             1                 1                     26h
longhorn-system   csi-attacher                                        1               N/A               2                     8h
longhorn-system   csi-provisioner                                     1               N/A               2                     8h
longhorn-system   instance-manager-c36384cab41c5643fb3ac92529788a0c   1               N/A               0                     20h
longhorn-system   instance-manager-fab969fd0e41cf59df06951809055bda   1               N/A               0                     20h

instance-manager の ALLOWED DISRUPTIONS が 0 になっています。Longhorn はボリュームのレプリカを退避し終えるまで、そのノードの instance-manager を落とさせません。退避が済むと ALLOWED DISRUPTIONS が上がり、evict が通ります。これは異常ではなく、データを守るための正常な待ちです。ここで --force を打つと、Longhorn の保護をすり抜けてボリュームを壊しかねません。

fanclub-db-0 が載っている側（本書ラボでは k8s-wl-02）の drain は、Workload Node が 2 台しかないので最後に必ず来ます。db-0 は反対側のノードで作り直され、backend はそれに合わせて入れ替わります。本書ラボでは drain が約 40 秒、その後 backend が 3 つとも 2/2 に戻るまで約 5 分でした。その間も https://fanclub.local は 200 を返し続けました（frontend が先に反対側へ退避され、DB を必要としないトップページは応答し続けるためです）。

本番ガードレール（4 件）#

ステップ7：全ノードのバージョンを確認する#

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

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

実行結果：

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

Client Version: v1.35.6
Kustomize Version: v5.7.1
Server Version: v1.36.3

200

kubectl version の Client Version が v1.35.6 のままである点を確認してください。API Server は v1.36.3 なので、±1 マイナーの範囲に収まっています。上げなくてよいものは上げない——これも判断のうちです。

ステップ8：本回の設定が生き残っているかを検算する#

ここが本回の締めです。 やってみよう④ のステップ1 で kubelet-config ConfigMap を先に直したことの効果を確認します。

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

# grep serverTLSBootstrap /var/lib/kubelet/config.yaml
# grep authentication-config /etc/kubernetes/manifests/kube-apiserver.yaml
# grep kubelet-certificate-authority /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果：

serverTLSBootstrap: true
    - --authentication-config=/etc/kubernetes/auth/anonymous.yaml
    - --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt

読み取るべき点は 2 つで、性質がまったく違います。

最後に、やってみよう④ のステップ7 と同じ 3 コマンドをもう一度打って、logs / exec / top が動くことを確かめてください。アップグレードのあとに動作確認まで行って、はじめて 1 サイクル完了です。

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

$ kubectl logs -n fanclub -l app=fanclub-frontend --tail=3
$ kubectl exec -n fanclub deploy/fanclub-frontend -- echo EXEC_OK
$ kubectl top nodes

実行結果：

2026/07/26 13:16:10 [notice] 1#1: start worker process 29
2026/07/26 13:16:10 [notice] 1#1: start worker process 30
2026/07/26 13:16:10 [notice] 1#1: start worker process 31
10.244.215.247 - - [26/Jul/2026:13:21:19 +0000] "GET / HTTP/1.1" 200 2600 "-" "curl/8.12.1" "10.244.119.128"

EXEC_OK

NAME        CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
k8s-cp-01   597m         29%      1956Mi          55%
k8s-cp-02   979m         48%      2310Mi          65%
k8s-cp-03   499m         24%      2231Mi          62%
k8s-wl-01   610m         15%      4781Mi          63%
k8s-wl-02   326m         8%       1396Mi          18%

アップグレード直後は Pod の再配置が続いているため、CPU 使用率は普段より高く出ます。数分待つと落ち着きます。

ステップ9：パッケージが上書きしたファイル権限を戻す#

ConfigMap に移せるのは kubeadm が管理するものだけです。 dnf が置き換えるファイルは、その外側にあります。第2回で 600 にした /usr/lib/systemd/system/kubelet.service は kubelet パッケージに含まれるファイルなので、アップグレードで 644 に戻ります。

実行コマンド（k8s-cp-01〜03 / k8s-wl-01〜02 上・root）：

# ls -l /usr/lib/systemd/system/kubelet.service

実行結果（644 に戻っています）：

-rw-r--r--. 1 root root 494  8月  1 00:00 /usr/lib/systemd/system/kubelet.service

タイムスタンプがパッケージのものに変わっていることが証拠です。5 台とも戻します。

実行コマンド（k8s-cp-01〜03 / k8s-wl-01〜02 上・root）：

# chmod 600 /usr/lib/systemd/system/kubelet.service
# kube-bench run --targets node --check 4.1.1 --benchmark cis-1.12

実行結果：

[PASS] 4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrictive

試験相当の粒度#

「指定された 1 ノードを vX.Y.Z へアップグレードせよ」という 1 問で 8〜12 分が目安です。試験では 1 ノード分なので、本演習の 5 段階を 1 セット打つ形になります。時間を落とさない要点は 3 つです。

• 1 台目かどうかで apply と node を使い分ける（間違えるとエラーで数分を失います）
• drain → パッケージ更新 → daemon-reload → restart kubelet → uncordon の順序を手に覚える
• 手順そのものは kubernetes.io/docs の kubeadm upgrade ページにあるので、暗記より「開いてなぞる」ほうが確実。ただしページを開く 1 分を惜しむなら順序だけは覚えておく

暗記必須コマンド（第5回）#

試験中に参照できるか#

この表そのものが教材です。 crictl は「Kubernetes 本体ではない道具」なので参照できないと思いがちですが、実際には kubernetes.io/docs にページがあります。逆にバージョンスキューは「公式の重要文書」であるにもかかわらず、/docs/ ではなく /releases/ にあるので開けません。

参照可否は、製品名や重要度で判断してはいけません。「そのページが許可された URL のサブパスにあるか」だけで決まります。 第1回で立てたこの基準を、本回で実地に落としました。試験前には、自分がよく使うページの URL を一度確認しておいてください。

最後に道具の話です。本文は読みやすさのため kubectl を全綴りで書いていますが、試験では alias k=kubectl を最初に張って k で打ってください。本回は static Pod の直接編集が中心なので --dry-run=client -o yaml の出番は少ないものの、kubectl certificate approve のようなワンライナーは k で打てると時間が浮きます。

まとめ#

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

• API Server は 認証 → 認可 → Admission の 3 つの関門でリクエストを処理する。401 なら認証層、403 なら認可層か Admission 層で、後者 2 つは拒否メッセージの文面で見分ける
• 匿名アクセスは既定で有効だが、RBAC（system:public-info-viewer）により /healthz /livez /readyz /version の 4 パス（/version/ を含めて 5 エントリ）だけが許されている。取れるのはバージョン情報であり、それは CVE の狙い撃ちに使える
• --anonymous-auth=false を素直に入れると kubeadm の 3 つの probe がすべて 401 になり、API Server が再起動ループに入る。 HA では他の 2 台が応答するため気づきにくく、CIS 1.2.1 は Manual なのでスコアも動かない
• 正しい締め方は --authentication-config で /livez /readyz /healthz だけ匿名を許すこと。--anonymous-auth とは排他で、両方は書けない
• 3 点セットは「常に 3 つ」ではない。 /etc/kubernetes/pki の中なら既存マウントで足りる（フラグのみ）、外なら 3 つとも要る
• --authorization-mode=Node,RBAC と NodeRestriction は kubeadm が既定で入れている。Node 認可は「他ノードのものを読ませない」、NodeRestriction は「自分のものでも触らせないフィールドがある」
• --enable-admission-plugins は既定への追加である。ラボの既定は 27 個だったが、マイナーごとに変わるので暗記せず --help で確かめる
• CIS 1.2.5 の恒久対応は serverTLSBootstrap: true + CSR の手動承認 + --kubelet-certificate-authority の 3 点。kubelet-serving の CSR は自動承認されない（自動承認は selfnodeclient だけ）
• kubeadm クラスタでは、ノード上のファイルは「結果」であって「正本」ではない。 kubeadm upgrade は /var/lib/kubelet/config.yaml を kubelet-config ConfigMap から、kube-apiserver.yaml を kubeadm-config ConfigMap から作り直す。手で足した設定は、この 2 つの ConfigMap（apiServer.extraArgs / extraVolumes を含む）に移していなければ消える
• 実行前に kubeadm upgrade apply --dry-run で「何を書こうとしているか」を確認する。 消えるかどうかは、打つ前に分かる
• 古いパッチに留まることは CVE を放置すること。アップグレードは Control Plane → Workload、1 台目は apply・以降は node、マイナーは 1 つずつ
• kube-bench は 44 PASS / 5 FAIL → 45 PASS / 4 FAIL になった。残る FAIL 4 件は監査ログで第16回に送る。WARN 11 件は本回の対処では動かない

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

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

1. kubelet-config ConfigMap を直さずに /var/lib/kubelet/config.yaml だけへ serverTLSBootstrap: true を書いた場合、kubeadm upgrade node を実行してもその設定は残る
2. 認証に失敗したリクエストには 403 が返る
3. 既定の設定では、匿名リクエストは認証を通過して system:anonymous として扱われる
4. --anonymous-auth=false を kubeadm クラスタの API Server に足すと、既定の probe が 401 になり再起動ループに入る
5. --anonymous-auth と --authentication-config（匿名を設定する場合）は同時に指定できる
6. static Pod にファイル参照フラグを足すときは、参照先が既存の volumeMounts に含まれていれば volumes の追加は不要である
7. --enable-admission-plugins=NodeRestriction と書くと、有効な Admission プラグインは NodeRestriction だけになる
8. kubelet が出す kubernetes.io/kubelet-serving の CSR は kubeadm クラスタでは自動承認される
9. パッチアップグレード（v1.36.2 → v1.36.3）ではリポジトリ URL の変更が必要である

次回予告#

第6回「カーネル層の強制アクセス制御（SELinux / seccomp / capabilities / AppArmor）」では、D3（System Hardening）に入り、クラスタ設定から OS・ノードの層へ降ります。本回まではすべて「API Server に届いたあと」の話でしたが、次回はコンテナがカーネルに対して何を要求できるかを絞ります。SELinux のラベルを読み、seccomp で syscall を制限し、capabilities を落とします。

本回で扱った「ベンチマークが通ることと安全であることは別」という論点は、次回でもう一度別の形で出てきます。ホストの SELinux が Enforcing であっても、コンテナが拘束されているとは限らないからです。

→ 詳しくは 第6回 カーネル層の強制アクセス制御（SELinux / seccomp / capabilities / AppArmor）

リンク