プロファイル適用性: レベル1
Kubeletサーバへの匿名リクエストを無効にします。
有効にすると、他の設定された認証方法によって拒否されないリクエストは匿名リクエストとして扱われます。これらのリクエストはKubeletサーバによって処理されます。アクセスを許可し、匿名リクエストを禁止するために認証に依存するべきです。
![]() |
注意GKEのドキュメントでデフォルト値を確認してください。
|
影響
匿名リクエストは拒否されます。
監査
監査方法1:
Kubeletは設定ファイルから設定を受け入れることができ、場合によってはコマンドライン引数からも受け入れることができます。コマンドライン引数として提供されたパラメータは、設定ファイル内の対応するパラメータを上書きすることに注意することが重要です
(詳細については、Kubelet CLIレファレンスの
--config
を参照してください。どの設定パラメータがコマンドライン引数として提供できるかも確認できます)。これを念頭に置いて、Kubeletの設定を監査する際には、コマンドライン引数の存在と設定ファイルのエントリの両方を確認することが重要です。- 各ノードにSSHで接続し、次のコマンドを実行してKubeletプロセスを見つけてください。
ps -ef | grep kubelet
上記のコマンドの出力は、アクティブなKubeletプロセスの詳細を提供します。これにより、プロセスに提供されたコマンドライン引数を確認できます。また、--config
引数で指定された設定ファイルの場所に注意してください。これは設定を確認するために必要です。 - ファイルは
more
やless
のようなコマンドで表示できます。sudo less /path/to/kubelet-config.json
- 匿名認証が有効になっていないことを確認してください。これは、kubeletサービスへのコマンドライン引数として
--anonymous-auth=false
を使用するか、kubelet設定ファイルで"authentication": { "anonymous": { "enabled": false }
として設定できます。
監査方法2:
KubernetesAPIの/configzエンドポイントを介して、Kubeletの実行中の設定を確認することも可能です。
kubectl
を使用して、APIへのリクエストをプロキシします。- 次のコマンドを実行して、クラスター内のすべてのノードを検出します。
kubectl get nodes
kubectl
を使用して、任意のローカルポートでプロキシを開始します。例:kubectl proxy --port=8080
- これを実行した状態で、別のターミナルで各ノードに対して次のコマンドを実行してください。
export NODE_NAME=my-node-name curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
curlコマンドは、Kubelet構成を表すJSON形式の文字列であるAPI対応を返します。 - API対応で
"authentication": { "anonymous": { "enabled": false }
が含まれていることを確認し、匿名認証が有効になっていないことを確認してください。
修復
修復方法1:
Kubelet設定ファイルを使用して設定する場合、まずファイルを見つけます:
- 各ノードにSSHで接続し、次のコマンドを実行してkubeletプロセスを見つけます。
ps -ef | grep kubelet
上記のコマンドの出力は、アクティブなkubeletプロセスの詳細を提供し、--config
引数でkubeletサービスに提供された設定ファイルの場所を確認できます。 - ファイルは
more
やless
のようなコマンドで表示できます。sudo less /path/to/kubelet-config.json
- 次のパラメータを設定して匿名認証を無効にします:
"authentication": { "anonymous": { "enabled": false } }
修復方法2:
- 実行可能な引数を使用する場合、各ワーカーノードのkubeletサービスファイルを編集し、以下のパラメータが
KUBELET_ARGS
変数文字列の一部であることを確認してください。 systemd
を使用するシステム、例えばAmazon EKS Optimized Amazon LinuxやBottlerocket AMIでは、このファイルは/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
にあります。- それ以外の場合は、選択したOSのドキュメントを参照して、どのサービスマネージャが設定されているかを確認する必要があります:
--anonymous-auth=false
.
両方の修復手順について:
お使いのシステムに基づいて、
kubelet
サービスを再起動し、サービスの状態を確認してください。以下の例は、Amazon EKS Optimised Amazon LinuxやBottlerocket AMIなど、systemd
を使用するOS向けであり、systemctl
コマンドを呼び出します。systemctl
が利用できない場合は、選択したOSにどのサービスマネージャが設定されているかを確認するためのドキュメントを参照する必要があります。
systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l