# Review kubelet serving CSRs separately from client bootstrap approval > Separate kubelet client credentials from serving-certificate requests, and review node identity and requested names before approving a serving CSR. - Canonical URL: https://update.dsesecurity.com/updates/review-kubelet-serving-csrs-separately-from-client-bootstrap-approval/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:46:46+00:00 - Modified: 2026-10-30T06:47:30+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Separate kubelet client credentials from serving-certificate requests, and review node identity and requested names before approving a serving CSR. ## Potentially affected Kubernetes deployments already using a kubelet serving-certificate CSR approval workflow. ## DSE recommendation Review serving-CSR identity, usages and node-bound names separately from client-bootstrap approval. ## Article Bottom line: Do not use client bootstrap success as the approval record for a kubelet serving certificate. Require a separate serving-CSR review when that workflow is already part of the deployment. ## Source fact: documented behavior The [TLS bootstrapping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) documentation is the primary reference. By default, the TLS-bootstrap client certificate is intended for client authentication and cannot serve as the kubelet’s HTTP serving certificate. Core Kubernetes CSR approvers do not approve kubelet serving certificates for security reasons. The documented serving-CSR checks include the node username and group, permitted server-certificate usages, node-owned IP or DNS names, and absence of email or URI alternative names. ## What the source does not establish This article reviews an existing serving-CSR approval path. It does not recommend enabling serving-certificate rotation, select an approver implementation or authorize a blanket approval rule. It also does not set a certificate lifetime or assume that every cluster uses the same signer and certificate-management arrangement. ## Applicability questions - Is the request for the kubelet as a client or as a server? - Which existing signer and approval process handle it? - What independent record establishes the node identity and its requested names? - Who reviews unexpected usages or alternative-name types? ## DSE recommendation: approve the requested identity rather than the queue DSE recommends a serving-CSR worksheet that separates requester identity, requested usages and requested names. Have the platform owner identify the trusted node inventory used for comparison. Keep that inventory independent of the request being evaluated so a submitted name is not its own evidence of ownership. Review the authenticated requester and node association before considering the certificate contents. Then compare each requested IP address and DNS name with the approved node record. Preserve an unexplained name as a reason for investigation rather than treating it as a harmless addition. Ask for a corrected request when the intended identity is unclear. Apply the reviewed usage and alternative-name checks through the deployment’s approved tooling. Keep private-key material out of the evidence. Record the signer, reviewer and reason for the decision, including why a rejected or deferred request did not meet the policy. For automated approval already in service, require a readable description of those same checks and an exception route. Review changes to that policy separately from a cluster enrollment exercise. A busy request queue should not turn into permission to approve every request associated with a familiar node name. ## Verification and evidence Proposed verification: prepare sanitized serving-CSR fixtures with a matching node identity and names, an unexpected DNS name, an unwanted usage and an inappropriate alternative-name type. Ask the approval owner to predict the disposition of each before evaluating them in a nonproduction approval workflow. Retain the parsed nonsecret request fields, independent node record and actual decisions. Keep client-bootstrap observations in a separate part of the record. Investigate any unexpected approval before wider use; do not issue a production certificate merely to determine whether the reviewer notices an out-of-policy field. ## Official references - [TLS bootstrapping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) — Kubernetes. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — TLS bootstrapping - Authority: kubernetes.io - URL: https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review kubelet serving CSRs separately from client bootstrap approval,” DSE Security, https://update.dsesecurity.com/updates/review-kubelet-serving-csrs-separately-from-client-bootstrap-approval/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.