Kubernetes Least Privilege Does Not End at the API Server
Kubernetes authorization reviews often focus on namespaced Roles and access to the API server. Node-level permissions receive less scrutiny because monitoring and support tools appear to need read-only infrastructure access.
That assumption creates dangerous privilege gaps. The kubelet API is a separate operational boundary, and broad proxy access can expose capabilities far beyond metrics or logs. Least privilege must cover the complete request path, not only the RBAC objects application teams see.
What matters
- Permission semantics: Evaluate what an integration can trigger through a node endpoint, not what its product description implies.
- Explicit access profiles: Separate metrics, health, logs, pod inspection, and execution into distinct platform-managed roles.
- Workload inventory: Find controllers and agents that depend on broad node proxy permissions before changing authorization policy.
- Controlled migration: Replace legacy grants with granular kubelet permissions, then remove the compatibility path.
- Continuous verification: Detect privilege expansion in deployment manifests and test denied operations as part of platform changes.
Recommendation
Treat kubelet authorization as a first-class part of the cluster security model. Standardize narrow access profiles for operational integrations and assign ownership for their lifecycle.
Fine-grained controls reduce blast radius only when broad legacy grants are removed. A precise API is useful; a disciplined operating model makes it effective.