Kubelet Authentication & Authorization

Reading time: 7 minutes

Kubelet Authentication

ドキュメントから:

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

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

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

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

• Webhook: これにより、kubectl APIベアラートークンが認証として有効になります（有効なトークンはすべて有効です）。次のように許可します：
• authentication.k8s.io/v1beta1 APIグループがAPIサーバーで有効になっていることを確認します
• **--authentication-token-webhookおよび--kubeconfig**フラグを使用してkubeletを起動するか、次の設定を使用します：

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

• 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"
}
},

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

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

• アクション

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

例えば、次のリクエストは、権限なしで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を受け取ったので、リクエストは認証チェックを通過しました。そうでなければ、Unauthorisedメッセージだけが表示されていたでしょう。
• ユーザー名（この場合はトークンから）を見ることができます。
• リソースがノードであり、サブリソースがプロキシであることを確認します（これは前の情報と一致します）。

References

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/