HackTricks CloudKubelet 認証と認可
Tip
学んで実践する AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks をサポートする
- subscription plans を確認してください!
- 参加する 💬 Discord group または telegram group に参加するか、Twitter 🐦 @hacktricks_live をフォローしてください。
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Kubelet 認証
デフォルトでは、他の設定された認証方法によって拒否されない kubelet の HTTPS エンドポイントへのリクエストは匿名リクエストとして扱われ、ユーザー名 system:anonymous と グループ system:unauthenticated が与えられます。
認証の 3 つの 方法 は次のとおりです:
- Anonymous (デフォルト): パラメータ
--anonymous-auth=trueまたは設定で有効にします:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: これにより kubectl の API bearer tokens を認証として有効にします（有効なトークンはどれでも認証されます）。次のように許可します：
- API サーバーで
authentication.k8s.io/v1beta1API グループが有効になっていることを確認する - kubelet を
--authentication-token-webhookと--kubeconfigフラグで起動するか、次の設定を使用する：
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
kubelet は設定された API server 上の
TokenReviewAPI` を呼び出し、bearer tokens からユーザー情報を判定します
- X509 client certificates: X509 client certs を使用して認証できます
- see the apiserver authentication documentation for more details
- kubelet を
--client-ca-fileフラグで起動し、クライアント証明書を検証するための CA バンドルを指定します。あるいは設定で:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Kubelet 認可
正常に認証された（匿名リクエストを含む）すべてのリクエストは、その後認可されます。デフォルトの認可モードは**AlwaysAllow**で、すべてのリクエストを許可します。
ただし、もう一つの可能な値は**webhook（現場で主に見かける**のはこちら）です。このモードは、アクションを許可するか拒否するかを決めるために、認証済みユーザーの権限をチェックします。
Warning
匿名認証が有効になっている場合でも、匿名アクセスは操作を実行するための権限を持たない場合があります。
webhookによる認可は、param --authorization-mode=Webhook を使用するか、設定ファイルで次のように設定できます：
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
The kubelet は構成された API サーバー上の SubjectAccessReview API を呼び出して、各リクエストが 許可されているかどうか を 判定 します。
kubelet は apiserver と同じ request attributes アプローチを使って API リクエストを認可します:
- アクション
| HTTP verb | request verb |
|---|---|
| POST | create |
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
| PUT | update |
| PATCH | patch |
| DELETE | delete (for individual resources), deletecollection (for collections) |
- Kubelet api に対して話す resource は 常に nodes で、subresource は受信リクエストのパスから 決定されます:
| Kubelet API | resource | subresource |
|---|---|---|
| /stats/* | nodes | stats |
| /metrics/* | nodes | metrics |
| /logs/* | nodes | log |
| /spec/* | nodes | spec |
| all others | nodes | proxy |
Note
WebSocket ベースの
/exec,/run,/attach,/portforwardはデフォルトの proxy subresource に分類され、初回 HTTP GET ハンドシェイクで認可されます。nodes/proxyGET のみを持つ主体でも、WebSockets 経由でhttps://<node_ip>:10250に直接接続すればコンテナを exec できてしまいます。詳細は nodes/proxy GET -> Kubelet /exec verb confusion abuse を参照してください。
例えば、次のリクエストは権限なしに kubelet の pods 情報へアクセスしようとしました:
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 を受け取ったので、リクエストは 認証チェックを通過している。もしそうでなければ、単に
Unauthorisedメッセージを受け取っていただろう。 - username が確認できる（この場合はトークンから）
- resource が nodes、subresource が proxy になっているのを確認（前の情報と一致する）
References
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
学んで実践する AWS Hacking:
学んで実践する GCP Hacking:
学んで実践する Az Hacking:HackTricks をサポートする
- subscription plans を確認してください!
- 参加する 💬 Discord group または telegram group に参加するか、Twitter 🐦 @hacktricks_live をフォローしてください。
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.