kubelet の clientCAFile 検証プロセスとは？

toshi

2025年2月3日 08:56

Kubernetes を運用するうえで、kubelet へのアクセス制御 は欠かせません。適切な設定をしないと、不正なアクセスを許してしまうリスクが生じます。

そこで重要になるのが clientCAFile です。これを設定すると、kubelet は「このクライアントは信頼できるのか？」をクライアント証明書を通じて判断できるようになります。

さらに、証明書の検証が通ったあとに「このクライアントは何ができるのか？」を制御するのが RBAC（Role-Based Access Control） です。

今回は、clientCAFile の検証プロセスと RBAC との関係について詳しく見ていきましょう。

(1) クライアント証明書が提示される

まず、kubelet の API にアクセスしようとするクライアント（例: kube-apiserver や Prometheus）は、クライアント証明書 を提示します。

この証明書には、次のような情報が含まれています。

発行者（Issuer）: 証明書を発行した認証局（CA）の情報
有効期限（Validity）: 証明書の有効期間
サブジェクト（Subject）: 証明書の所有者（通常はクライアントの ID）
デジタル署名: 証明書が改ざんされていないことを保証する署名

クライアント証明書は client.crt（証明書）と client.key（秘密鍵）のペアで使われ、以下のようにリクエストを送ります。

curl --cert /path/to/client.crt \
     --key /path/to/client.key \
     --cacert /etc/kubernetes/pki/ca.crt \
     https://<node-ip>:10250/metrics

しかし、証明書を提示しただけでは kubelet にアクセスできません。次に、kubelet は clientCAFile を使って証明書の検証を行います。

(2) clientCAFile に登録された CA で証明書を検証

kubelet は、設定された clientCAFile（例: /etc/kubernetes/pki/ca.crt）を使って、以下のチェックを行います。

(1) 証明書の署名をチェック

証明書の発行元が、信頼できる CA なのかを確認します。

✅ OK の場合
「この証明書は信頼できる CA によって発行されたものだ！」 → 次のチェックへ進む

❌ NG の場合
「この証明書は不正な CA によるものか、改ざんされている！」 → リクエストを拒否

(2) 証明書の有効期限をチェック

証明書の Not Before（開始日時）と Not After（終了日時）を見て、現在の時刻がこの範囲内にあるかを確認します。

✅ OK の場合
「証明書の期限内だ！」 → 次のチェックへ進む

❌ NG の場合
「証明書の有効期限が切れている！」 → リクエストを拒否

(3) CN（Common Name）または SAN（Subject Alternative Name）の確認

証明書の CN（Common Name）や SAN（Subject Alternative Name） を確認し、「このクライアントが kubelet API にアクセスできる資格を持っているか？」を判断します。

具体的には、kubelet は以下の処理を行います。

① CN や SAN の値を取得

証明書の CN や SAN に含まれる値を抽出し、リクエストを送信したクライアントの ID を特定します。

例えば、クライアント証明書の CN が system:kube-apiserver の場合、これは Kubernetes の API サーバーが kubelet へアクセスするための証明書であることを意味します。

Subject: CN=system:kube-apiserver

② 証明書の CN/SAN が適切かを判断

Kubernetes では、kubelet へのアクセス権限を持つ CN を事前に決めておきます。例えば、system:kube-apiserver や system:node:<node-name> などが適切な CN です。

kubelet は、受け取った証明書の CN/SAN が RBAC で定義されたユーザーやサービスアカウントと一致するか を確認します。

✅ OK の場合
「このクライアントは適切な ID を持っている！」 → RBAC によるアクセス制御へ進む

❌ NG の場合
「このクライアントの ID は kubelet API へのアクセスを許可されていない！」 → リクエストを拒否

(3) RBAC によるアクセス制御

ここまでの検証に合格したクライアントは、「kubelet の API にアクセスできるかどうか」を認証されました。ただし、それだけでは「何ができるか？」までは決まりません。

ここで登場するのが RBAC（Role-Based Access Control） です。

RBAC 設定の具体例

以下の RBAC 設定では、system:monitoring という CN を持つクライアントに対し、kubelet のメトリクスを取得する権限を付与しています。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-metrics-reader
rules:
- apiGroups: [""]
  resources: ["nodes/metrics"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-kubelet-metrics
subjects:
- kind: User
  name: system:monitoring  # 証明書の CN に一致する必要がある
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kubelet-metrics-reader
  apiGroup: rbac.authorization.k8s.io

この設定により、system:monitoring という証明書を持つクライアントだけが nodes/metrics のデータを取得できます。

まとめ

clientCAFile は、kubelet がクライアント証明書の信頼性を確認するための設定
証明書の 署名・有効期限・CN/SAN をチェックし、正当なリクエストのみ許可する
証明書の CN/SAN を確認することで、「このクライアントが kubelet API にアクセスできる資格があるか」を判断する
証明書の検証に通った後、RBAC によってアクセス権が決定される

適切に clientCAFile と RBAC を設定し、kubelet API へのアクセスを安全に管理しましょう！