WG-Creation-Request: WG Node Identity

[Naadir Jeewa]

Hi all,

We would like to propose the formation of WG Node Identity, a working group focused on bringing hardware-backed node attestation into Kubernetes core.

Problem Statement

Hardware attestation — using TPMs, vTPMs, or cloud instance identity documents — can be integrated with kubelets to prove their identity during CSR submission, and projects and vendors have implemented this in various ways without a common model.

For users following the Getting Started guides on their own hardware, the most detailed method (kubeadm) currently relies on bootstrap tokens for node registration via TLS bootstrapping. This model is trust-on-first-use: any bearer of a valid token can register as any node name, and there is no mechanism for the control plane to cryptographically verify that a kubelet is running on the machine it claims to be. This creates a class of node impersonation attacks where a compromised token allows an attacker to register as an existing node (including control plane nodes) and gain access to secrets and volumes intended for that node.

Our goal is to make attestation bootstrap  as simple as the TLS bootstrap tokens mechanism — enabled out of the box on platforms that support it, with zero or minimal configuration with a common model across implementations. Secure node identity should be the easy path, not an advanced or vendor specific option that operators have to discover and configure.

Why a Working Group

Node identity spans three SIGs:

• SIG Auth owns the certificate signing infrastructure, CSR approval, and trust model

• SIG Node owns the kubelet, including TLS bootstrap and certificate rotation

• SIG Cluster Lifecycle owns a number of cluster lifecycle management solutions which need to provide attested clusters.

• SIG Cloud Provider owned some extant implementations, such as GCP (historical)

No single SIG owns the full path from hardware identity to approved kubelet certificate. A WG provides the cross-SIG coordination venue to design this holistically. Subprojects within SIG Cluster Lifecycle have pursued their own implementations out of necessity but in an ad hoc fashion we would now like to formalise.

Participating SIGs

• SIG Cluster Lifecycle: sponsoring SIG

• SIG Autoscaling: a consumer

• SIG Node: participating SIG

Proposed Chairs

• Rodrigo Campos Catelin (@rata) - Amutable

• Ciprian Hacman (@hakman) - Microsoft

• Naadir Jeewa (@randomvariable) - VMware by Broadcom

• Michael McCune (@elmilko) - Red Hat

• Josephine Pfeiffer (@pfeifferj) - Red Hat

Organisational Diversity

We have participation from Broadcom, Google, Red Hat, Microsoft, Amutable, and the kOps community. Each organisation brings distinct attestation mechanisms and distribution requirements covering hyperscalers, Linux distribution expertise, virtualised and bare metal private clouds. There was also significant practitioner interest at Kubecon EU 2026, and we would welcome contributors from all geographies and backgrounds to join us.

Charter

The full draft charter is available at: https://github.com/kubernetes/community/pull/9028/changes#diff-d2ad503679e32d3341465713ed73257713a89ddf4a25000210c4e96bee64f38b 

Next Steps

We are looking for:

1. Feedback on the charter PR scope and approach from SIG Autoscaling, SIG Node, and SIG Cluster Lifecycle leads

(Note: We have already done a bit of a roadshow across SIG meetings)

2. Expressions of interest from anyone working on node identity, trusted computing, or platform attestation in the Kubernetes ecosystem

If there is sufficient interest, we will complete the charter PR to kubernetes/community with the committee/steering label.

Thanks, Rodrigo Campos Catelin (@rata) , Ciprian Hacman (@hakman) , Naadir Jeewa (@randomvariable), Michael McCune (@elmilko) , Josephine Pfeiffer (@pfeifferj)

[Taahir Ahmed]

I have been slowly cooking a SIG Auth proposal for building TPM-authenticated certificate requests directly into Kubelet / K8s APIs.  I (and several other folks from my team, including @Harshal Neelkamal) would love to participate in this effort.

I reviewed the proposed charter, and it seems well-scoped and complete to me.

--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAHTZsqS7nn8NbW0pxDxF0uee7f94m9nyqbULth8U6EiBZFi%2BFg%40mail.gmail.com.

[Jack Francis]

SIG Autoscaling would be happy to prioritize the consumer persona to support this effort. 👍