Kubelet authentication/authorization

    This document describes how to authenticate and authorize access to the kubelet’s HTTPS endpoint.

    By default, requests to the kubelet’s HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests, and given a username of and a group of system:unauthenticated.

    To disable anonymous access and send 401 Unauthorized responses to unauthenticated requests:

    • start the kubelet with the --anonymous-auth=false flag
    • start the kubelet with the --client-ca-file flag, providing a CA bundle to verify client certificates with
    • start the apiserver with --kubelet-client-certificate and flags

    To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet’s HTTPS endpoint:

    • ensure the authentication.k8s.io/v1beta1 API group is enabled in the API server
    • start the kubelet with the --authentication-token-webhook and --kubeconfig flags
    • the kubelet calls the TokenReview API on the configured API server to determine user information from bearer tokens

    Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is AlwaysAllow, which allows all requests.

    There are many possible reasons to subdivide access to the kubelet API:

    • anonymous auth is enabled, but anonymous users’ ability to call the kubelet API should be limited
    • bearer token auth is enabled, but arbitrary API users’ (like service accounts) ability to call the kubelet API should be limited
    • client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
    • start the kubelet with the --authorization-mode=Webhook and the --kubeconfig flags
    • the kubelet calls the SubjectAccessReview API on the configured API server to determine whether each request is authorized

    The kubelet authorizes API requests using the same approach as the apiserver.

    The verb is determined from the incoming request’s HTTP verb:

    The resource and subresource is determined from the incoming request’s path:

    Kubelet APIresourcesubresource
    /stats/nodesstats
    /metrics/nodesmetrics
    /logs/nodeslog
    /spec/nodesspec
    all othersnodesproxy

    When running in this mode, ensure the user identified by the --kubelet-client-certificate and flags passed to the apiserver is authorized for the following attributes:

    • verb=*, resource=nodes, subresource=proxy
    • verb=*, resource=nodes, subresource=stats
    • verb=*, resource=nodes, subresource=log
    • verb=*, resource=nodes, subresource=spec