Using Node Authorization

    The Node authorizer allows a kubelet to perform API operations. This includes:

    Read operations:

    • services
    • endpoints
    • nodes
    • pods
    • secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet’s node

    Write operations:

    • nodes and node status (enable the admission plugin to limit a kubelet to modify its own node)
    • events

    Auth-related operations:

    • read/write access to the certificationsigningrequests API for TLS bootstrapping
    • the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks

    In future releases, the node authorizer may add or remove permissions to ensure kubeletshave the minimal set of permissions required to operate correctly.

    In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them asbeing in the system:nodes group, with a username of system:node:<nodeName>.This group and user name format match the identity created for each kubelet as part ofkubelet TLS bootstrapping.

    To enable the Node authorizer, start the apiserver with —authorization-mode=Node.

    To limit the API objects kubelets are able to write, enable the admission plugin by starting the apiserver with —enable-admission-plugins=…,NodeRestriction,…

    Kubelets outside the group would not be authorized by the Node authorization mode,and would need to continue to be authorized via whatever mechanism currently authorizes them.The node admission plugin would not restrict requests from these kubelets.

    In some deployments, kubelets have credentials that place them in the system:nodes group,but do not identify the particular node they are associated with,because they do not have a username in the system:node:… format.These kubelets would not be authorized by the Node authorization mode,and would need to continue to be authorized via whatever mechanism currently authorizes them.

    The NodeRestriction admission plugin would ignore requests from these kubelets,since the default node identifier implementation would not consider that a node identity.

    Upgraded pre-1.7 clusters using RBAC will continue functioning as-is because the system:nodes group binding will already exist.

    • Enable the Node authorization mode (—authorization-mode=Node,RBAC) and the NodeRestriction admission plugin
    • Ensure all kubelets’ credentials conform to the group/username requirements
    • Audit apiserver logs to ensure the authorizer is not rejecting requests from kubelets (no persistent NODE DENY messages logged)

    In 1.6, the system:node cluster role was automatically bound to the system:nodes group when using the .

    In 1.7, the automatic binding of the system:nodes group to the system:node role is deprecatedbecause the node authorizer accomplishes the same purpose with the benefit of additional restrictionson secret and configmap access. If the Node and RBAC authorization modes are both enabled,the automatic binding of the system:nodes group to the system:node role is not created in 1.7.

    In 1.8, the binding will not be created at all.

    When using RBAC, the system:node cluster role will continue to be created,for compatibility with deployment methods that bind other users or groups to that role.

    Was this page helpful?

    Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it onStack Overflow.Open an issue in the GitHub repo if you want toorsuggest an improvement.