[PixiBixi]

Each HAProxy instance generates its own TLS ticket keys, and new ones on every reload. Behind several replicas (DNS round robin, a load balancer without affinity), a client that lands on another replica, or comes back after a reload, cannot resume its session and pays a full handshake.

This adds a tls-ticket-keys ConfigMap annotation holding the path of a keys file, typically mounted from a Secret:

• MEDIUM: ssl: add the tls-ticket-keys configmap annotation: sets tls-ticket-keys <file> on the v4, v6 and ssl-passthrough binds of the https frontend when SSL offload is enabled. The quic binds are left untouched. An unreadable path is ignored, since HAProxy would reject the configuration. A reload is requested only when a bind changes.
• MEDIUM: ssl: rotate tls-ticket-keys through the runtime API: on every sync tick, when the file changed, the controller compares the loaded keys (show tls-keys) with the last three lines of the file and pushes only the missing ones with set ssl tls-key. A rotation therefore needs no reload. A failed runtime update falls back to a reload.

The Frontend v3 custom resource has a tls_ticket_keys field, but the controller-owned binds win the merge, so it cannot set it on the https binds today.

Tests

• Unit tests for the bind update and the rotation diff (pkg/handler, pkg/controller).
• On kind, 2 replicas with the companion chart change (MINOR: kubernetes-ingress: add TLS ticket keys support helm-charts#400):
  • the generated config carries tls-ticket-keys on the v4 and v6 binds only;
  • openssl s_client -sess_out on replica A then -sess_in on replica B: Reused with TLS 1.2 and 1.3, New without the annotation;
  • after rotating the Secret (drop the first key, append one): pushed a rotated key in both controllers, no reload, show tls-keys matching the new file, and a ticket issued before the rotation still Reused on the other replica.