Japanese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubelet Authentication & Authorization

Support HackTricks

Kubelet Authentication

From the docss:

デフォルトでは、他の設定された認証方法によって拒否されないkubeletのHTTPSエンドポイントへのリクエストは、匿名リクエストとして扱われ、ユーザー名は system:anonymous、**グループは system:unauthenticated**が与えられます。

3つの 認証 方法 は次のとおりです：

  • 匿名（デフォルト）：パラメータ --anonymous-auth=true または設定を使用します：

"authentication": {
"anonymous": {
"enabled": true
},

  • Webhook: これにより、kubectl APIベアラートークンが認証として有効になります（有効なトークンはすべて有効です）。次のように許可します：

  • APIサーバーでauthentication.k8s.io/v1beta1 APIグループが有効になっていることを確認します

  • **--authentication-token-webhookおよび--kubeconfig**フラグを使用してkubeletを起動するか、次の設定を使用します：

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

kubeletは、設定されたAPIサーバー上で**TokenReview API**を呼び出して、ベアラートークンからユーザー情報を特定します

  • X509クライアント証明書: X509クライアント証明書を介して認証を許可します

  • 詳細については、apiserver認証ドキュメントを参照してください

  • --client-ca-fileフラグを使用してkubeletを起動し、クライアント証明書を検証するためのCAバンドルを提供します。または、設定を使用して:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

成功裏に認証された（匿名リクエストを含む）すべてのリクエストはその後承認されます。デフォルトの承認モードは**AlwaysAllow**で、すべてのリクエストを許可します。

しかし、他の可能な値は**webhookであり（これは主に見つかるものです**）、このモードは認証されたユーザーの権限を確認してアクションを許可または拒否します。

匿名認証が有効になっている場合でも、匿名アクセスにはアクションを実行する権限がない可能性がありますので注意してください。

Webhookによる承認は、**パラメータ --authorization-mode=Webhook**を使用するか、設定ファイルで構成できます：

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

The kubeletは、設定されたAPIサーバー上で**SubjectAccessReview** APIを呼び出して、各リクエストが認可されているかどうかを 判断します。

kubeletは、apiserverと同じリクエスト属性アプローチを使用してAPIリクエストを認可します：

  • アクション

HTTP動詞リクエスト動詞

POST

create

GET, HEAD

get（個々のリソース用）、list（コレクション用、完全なオブジェクトコンテンツを含む）、watch（個々のリソースまたはリソースのコレクションを監視するため）

PUT

update

PATCH

patch

DELETE

delete（個々のリソース用）、deletecollection（コレクション用）

  • Kubelet APIと通信するリソースは常に nodesであり、サブリソースは受信リクエストのパスから決定されます：

Kubelet APIリソースサブリソース

/stats/*

nodes

stats

/metrics/*

nodes

metrics

/logs/*

nodes

log

/spec/*

nodes

spec

その他すべて

nodes

proxy

例えば、次のリクエストは、権限なしでkubeletのポッド情報にアクセスしようとしました：

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

  • Forbiddenを受け取ったので、リクエストは認証チェックを通過しました。そうでなければ、単にUnauthorizedメッセージが表示されていたでしょう。

  • ユーザー名（この場合はトークンから）を見ることができます。

  • リソースがnodesで、サブリソースがproxyであることを確認します（これは前の情報と一致します）。

参考文献

HackTricksをサポートする
PreviousPentesting Kubernetes ServicesNextExposing Services in Kubernetes

Last updated