Kubelet Authentication & Authorization
Kubelet 認証
デフォルトでは、他の構成された認証方法で拒否されない kubelet の HTTPS エンドポイントへのリクエストは匿名リクエストとして扱われ、ユーザー名が system:anonymous
で、グループが system:unauthenticated
として与えられます。
認証方法は 3 つあります:
匿名 (デフォルト): パラメータ **
--anonymous-auth=true
を設定するか、設定ファイルを使用します:
Webhook: これにより、kubectl APIベアラートークンを認証として有効にします(有効なトークンはすべて有効です)。次のように許可します:
APIサーバーで
authentication.k8s.io/v1beta1
APIグループが有効になっていることを確認しますkubeletを**
--authentication-token-webhook
および--kubeconfig
**フラグで起動するか、次の設定を使用します:
kubeletは、構成されたAPIサーバー上で**TokenReview
APIを呼び出して、ベアラートークンからユーザー情報を決定**します。
X509クライアント証明書: X509クライアント証明書を使用して認証を許可します
詳細については、apiserver認証ドキュメントを参照してください
--client-ca-file
フラグを使用して、クライアント証明書を検証するためのCAバンドルを提供してkubeletを起動します。または、次の構成で開始します:
Kubelet 認可
認証に成功したリクエスト(匿名リクエストを含む)はその後認可されます。デフォルトの認可モードは**AlwaysAllow
**で、すべてのリクエストを許可します。
ただし、他の可能な値は**webhook
**です(ほとんどの場所で見つけることができるものです)。このモードでは、認証されたユーザーの権限をチェックして、アクションを許可または拒否します。
匿名認証が有効になっていても、匿名アクセスはアクションを実行するための権限を持っていない可能性があります。
Webhookを介した認可は、--authorization-mode=Webhook
パラメータを使用するか、次のように構成ファイルを介して行うことができます:
kubeletは、各リクエストが認可されているかを判断するために、設定されたAPIサーバー上で**SubjectAccessReview
** APIを呼び出します。
kubeletは、APIリクエストを認可する際に、apiserverと同じリクエスト属性アプローチを使用します:
アクション
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のポッド情報にアクセスしようとしました:
私たちはForbiddenを受け取ったので、リクエストは認証チェックをパスしました。そうでなければ、単に
Unauthorised
メッセージを受け取っただけです。ユーザー名(この場合はトークンから)
リソースがnodesであり、サブリソースがproxyであることを確認します(前の情報と一致します)
参考文献
Last updated