Kubelet Authentication & Authorization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
デフォルトでは、他の設定された認証方法によって拒否されないkubeletのHTTPSエンドポイントへのリクエストは、匿名リクエストとして扱われ、ユーザー名は system:anonymous、**グループは system:unauthenticated**が与えられます。
3つの 認証 方法 は次のとおりです：
匿名 (デフォルト): パラメータ --anonymous-auth=true または設定を使用します：
Webhook: これにより、kubectl APIベアラートークンが認証として有効になります（有効なトークンはすべて有効です）。次のように許可します：
APIサーバーでauthentication.k8s.io/v1beta1 APIグループが有効になっていることを確認します
**--authentication-token-webhookおよび--kubeconfig**フラグを使用してkubeletを起動するか、次の設定を使用します：
kubeletは、設定されたAPIサーバー上で**TokenReview API**を呼び出して、ベアラートークンからユーザー情報を特定します
X509クライアント証明書: X509クライアント証明書を介して認証を許可します
詳細については、apiserver認証ドキュメントを参照してください
--client-ca-fileフラグを使用してkubeletを起動し、クライアント証明書を検証するためのCAバンドルを提供します。または、設定を使用して:
成功裏に認証された（匿名リクエストを含む）すべてのリクエストは、その後承認されます。デフォルトの承認モードは**AlwaysAllow**で、すべてのリクエストを許可します。
しかし、他の可能な値は**webhookであり（これは主に見つかるものです**）、このモードは認証されたユーザーの権限を確認して、アクションを許可または拒否します。
匿名認証が有効になっている場合でも、匿名アクセスにはアクションを実行する権限がない可能性がありますので注意してください。
Webhookによる承認は、**パラメータ --authorization-mode=Webhook**を使用するか、設定ファイルで次のように構成できます：
kubeletは、各リクエストが認可されているかどうかを判断するために、構成されたAPIサーバーで**SubjectAccessReview** APIを呼び出します。
kubeletは、apiserverと同じリクエスト属性アプローチを使用してAPIリクエストを認可します：
アクション
POST
create
GET, HEAD
get（個別リソース用）、list（コレクション用、完全なオブジェクトコンテンツを含む）、watch（個別リソースまたはリソースのコレクションを監視するため）
PUT
update
PATCH
patch
DELETE
delete（個別リソース用）、deletecollection（コレクション用）
Kubelet APIと通信するリソースは常に****ノードであり、サブリソースは受信リクエストのパスから決定されます：
/stats/*
nodes
stats
/metrics/*
nodes
metrics
/logs/*
nodes
log
/spec/*
nodes
spec
その他すべて
nodes
proxy
例えば、次のリクエストは、権限なしでkubeletのポッド情報にアクセスしようとしました：
Forbiddenを受け取ったので、リクエストは認証チェックを通過しました。そうでなければ、単にUnauthorizedメッセージが表示されていたでしょう。
ユーザー名（この場合はトークンから）を見ることができます。
リソースがnodesで、サブリソースがproxyであることを確認します（これは前の情報と一致します）。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
