Files
Aleksei Sviridkin df85632c89 fix(cert-manager): move the webhook off the kubelet's port
The vendored chart defaults webhook.securePort to 10250, which is the
port the kubelet serves on. Upstream picks that value deliberately, for
GKE private clusters where apiservers may reach nodes only on 443 and
10250; it is free of consequence there and unsafe here.

When a connection to the webhook Service resolves to a node IP instead
of a Pod IP, it reaches the kubelet, which completes the TLS handshake
with its node serving certificate. The apiserver then rejects every
cert-manager admission call in the cluster with

  x509: certificate is valid for <node>, not
  cert-manager-webhook.cozy-cert-manager.svc

and, because the webhook is failurePolicy: Fail, that stalls platform
bootstrap. The certificate is valid; it is simply the wrong server's.
The error names cert-manager and points away from the routing layer
that actually failed, which makes a rare misroute expensive to
diagnose.

Serve on 10260 instead, the port upstream's troubleshooting guide
prescribes for this exact error. It documents the failure on EKS
Fargate, where a microVM forwards every port to the pod except the one
its own kubelet already holds; the cause there is understood and ours
is not, but the shape is the same, down to the certificate that comes
back naming the node. What the fix needs of the port is that nothing
answers on it in a node's network namespace, and nothing in the
platform does. The same misroute is then refused at connect time, which
is an honest and immediately diagnosable error. This does not prevent
the misroute, whose cause is unestablished; it removes the collision
that turns one into a cluster-wide failure attributed to the wrong
component.

The Service targets the container port by name, so it follows the
change without an edit, and a rolling update resolves the old and new
ports per Pod rather than dropping the endpoint. Tests pin the listener
flag together with the advertised containerPort so the two cannot drift
apart.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
2026-07-20 00:20:06 +03:00
..
2024-02-08 12:04:32 +01:00