How about: NodeCertificateNameValidation?

The API server is verifying a certificate presented by a node, whatever software that node is running (which, OK, is very likely to be kubelet).

if this actor is already owning a node in the cluster then exec and logs does not need to impersonate a node, they just target pods in a node, and require the kubelet to terminate the connection

I don't think I get this one, sorry :(
Could you elaborate a bit?

Maybe this line needs a bit of clarification. What this attack breaks is the confidentiality of requests aimed nodes other than the node the attacker controls.

what I tried to mean is that it if already owns the Node why it should try to impersonate it?

but IIUIC this is based on the idea of stealing a valid certificate of a node and own a node in the same network not part of the cluster

Yeah. It's about stealing the certificate from one node and being able to impersonate any other node that gets assigned the same IP for the TTL of the certificate.

can you expand on the "reroute traffic to itself" problem?
I may not get all the full details of the scenario, nodeA with IP1 is removed but somehow actorB manages to get its certificate, spawn a nodeB with nodeA name? IP2 or IP1??? , join it to the cluster and set the address IP1 on node.status.addresses ?

For example:

1. Node A has IP1 and gets a cert issues for IP1. Cert is valid for a year.
2. An attacker gets control over Node A and gets this certificate.
3. Node A is recycled.
4. Eventually, a Node B is created and since IP1 is now free, it gets IP1 assigned.
5. The attacker is still in the network, let's say with control of Machine C with IP2. It redirects traffic going to IP1 to Machine C, for example with an ARP poisoning attack, and uses the certificate it obtained from Node A, which is valid for IP1.
6. If a exec/log request is performed aimed at a pod in Node B, the Kube-API server will trust Machine C to be Node B.

node name has the cardinality problem, but leaving the metric sounds like a good thing to me, it can help to detect issues with the node certificates due to bugs per example

remember you need to add the flag only if the feature flag is enabled, otherwise if the feature does not progress removing the flag can not be possible without breaking the users that are already setting it

do you have a proof-of-concept of the wiring / wrapping for this validation? I poked around at the kube-apiserver → node network paths and didn't see an obvious spot to wire something at the connection level that had visibility to the node name and the serving certificate

Yeah I do. Take it as a first draft. For example, I'm still on the fence about caching/trying to cache this in the client-go transport package.
https://github.com/kubernetes/kubernetes/compare/master...g-gaston:kubernetes:kubelet-serving-cert-cn-validation-poc?expand=1

Ah also I haven't implemented feature gates or metrics.

Hmm... thanks for the pointer... that's about as twisty as what I was afraid my exploration was going to turn into :-/

I think that approach is going to leak client transports in kube-apiserver... currently, there's a single transport for all kube-apiserver → kubelet connections. This approach looks like it will make a new transport per node, which gets held forever in the transport tlsCache ... so as nodes cycle in/out of a cluster, the kube-apiserver client cache will just grow unbounded :-/

we need to make sure we have a plausible way to hook in this validation that won't leak in that way

(cc @aojea @enj for client cache fun :-/)

Indeed, that's why i was on the fence about the caching

The two alternatives I can see are to not cache these transports at all (either by making transports with custom cert validation uncachable or by allowing to mark a transport as uncachable and doing that explicitly for the ones we create) or to add a cache invalidation mechanism. Leaning towards the first one. The drawback is the overhead of creating a transport on the fly per request.