Hi Lorenzo, Thank you for the clarifications, this makes sense to me.
-- Anton ср, 24 июн. 2026 г. в 16:16, Lorenzo Affetti via dev <[email protected]>: > > Hi Giannis, Anton, > > Thanks for the detailed reviews. I've updated the FIP to address all > points raised. You can find the summary of changes below and a diff attached > for your convenience. > > --- > > Zero-copy (Giannis Q1, Anton) > > This was a big oversight on my part; I apologize. > Thanks for unveiling this. > > You are both correct. TLS and sendfile are mutually exclusive: SslHandler > requires bytes in JVM-managed memory before encryption, which is > incompatible with FileChannel.transferTo(). On TLS-enabled listeners, log > fetch responses are copied into a buffer in the JVM before encryption. > Plaintext listeners are unaffected. This is the same trade-off Apache Kafka > makes with SSL. > > I've added a "Performance trade-off: zero-copy" subsection to the FIP that > calls this out explicitly, so operators can account for it in capacity > planning. kTLS is now explicitly listed as Out of Scope rather than left > implied. > > --- > > Short-lived credentials (Giannis Q2) > > The design does not assume short-lived credentials. Hot-reload is entirely > opt-in: setting security.ssl.reload.interval=0 disables polling, and the > system works correctly with static long-lived certificates. Rotation in that > model is handled with an explicit rolling restart, exactly as any other > config change today. The 5-minute default targets cloud-native deployments; > if files never change, reload is a no-op. > > I've added an explicit note on static/long-lived certs to the hot-reload > section. > > --- > > Non-goals (Anton) > > Added a dedicated Non-Goals section covering ZooKeeper connection security, > remote storage encryption, and data at rest. The FIP now states explicitly > that enabling RPC TLS does not imply end-to-end cluster encryption. > > --- > > Configuration validation (Anton) > > Expanded to a fail-fast startup validation table covering the cases you > listed. > > --- > > Metrics (Anton) > > The two metrics you flagged are promoted to v1: > > - tls.handshake.failures (counter, per listener): matches > Kafka's failed-authentication-total. Handshake failures are below > the normal RPC error path; logs-only is effectively invisible in > production. > > - tls.certificate.days.to.expiry (gauge, per listener): fills the > gap Kafka has never closed, enabling expiry alerting before it > becomes a handshake failure. > > On the reactive self-healer: I agree the interval-only model is > simpler and closer to what Kafka ships. However, the reactive trigger > provides a concrete safety guarantee that the interval-only model > cannot: a certificate renewed just after a poll is adopted on the > next connection attempt rather than after up to reload.interval. For > short-lived certs (e.g., 1-hour SPIFFE SVIDs) with a 5-minute poll > interval, that window matters. The reactive logic is also isolated and > safe by construction: rate-limited, never swaps in a broken context, > and does not retry the triggering connection. I'd like to keep it in > v1. Happy to discuss further on the list if you feel strongly about > deferring it. > > --- > > SslPrincipalMapper (Anton) > > Added explicit fail-fast behaviour: unsupported rule grammar causes the > server to refuse to start, not fail at authentication time. This is the > right place — the rules are static config, validation is cheap (regex > compile), and startup failure is far more diagnosable than a per- > connection authorization failure that looks like an ACL misconfiguration. > The validation table in the FIP now has an eighth row for this. > > --- > > Let me know if > anything needs further discussion. > > Best, > Lorenzo > > On Fri, Jun 19, 2026 at 6:58 AM Giannis Polyzos <[email protected]> wrote: >> >> Hi Lorenzo, >> thank you for the really nice and detailed FIP. >> >> May I suggest attaching the link to the proposal? >> https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support >> >> Overall the proposal looks great and looks solid to me. >> Two questions I have just for clarity: >> 1. Netty’s SslHandler can’t encrypt a FileRegion.. Does this mean that TLS >> enables clients will lose zero-copy? Or is there a workaround for this? If >> not I think maybe it would be good to explicitly mention this in the >> proposal so users are aware of this trade-off >> >> 2. Does the design assume always short-lived credentials? >> >> Overall it looks good to me and it’s a +1 on my side. >> >> Best, >> Giannis >> >> On Fri, 12 Jun 2026 at 5:44 PM, Lorenzo Affetti via dev >> <[email protected]> wrote: >>> >>> Hello community! >>> >>> I would like to start a discussion about FIP-29: (m)TLS support. >>> >>> Here is the motivation: >>> >>> All Fluss RPC traffic — between clients and servers, and between servers — >>> currently travels over the network *in plaintext*. >>> >>> This has two consequences: >>> >>> 1. *Confidentiality.* Table data, metadata, and even the credentials >>> exchanged by the existing application-layer authentication are visible to >>> anyone able to observe the network. In shared, cloud, or multi-tenant >>> deployments this is unacceptable. >>> 2. *Strong client authentication.* Fluss has a pluggable authentication >>> framework, but it has no certificate-based mechanism. Operators who >>> standardize on PKI / mutual TLS for service-to-service identity (a very >>> common requirement) cannot integrate Fluss. >>> >>> This FIP adds: >>> >>> - *TLS transport encryption* for the Netty RPC layer, enabled per server >>> listener and on the client. >>> - *Mutual TLS (mTLS) authentication*, where the server derives the >>> authenticated FlussPrincipal from the client's X.509 certificate, >>> integrated into the existing authentication/authorization pipeline. >>> >>> >>> Eager to hear about your thoughts! >>> >>> -- >>> Lorenzo Affetti >>> Team Leader of Stream Storage >>> [email protected] >>> www.ververica.com >>> ------------------------------ >>> >>> <https://www.ververica.com/> >>> Ververica GmbH | Herzogspitalstrasse 24 | 80331 München | Germany >>> >>> Follow us: >>> <https://www.linkedin.com/company/ververica/posts/?feedView=all> >>> <https://www.youtube.com/@ververica> >>> <https://open.spotify.com/show/2XME9h8iBOyr6YupqM99ir?si=87b064644add42a1>Available >>> on: <https://aws.amazon.com/marketplace/pp/prodview-luvmqd6leha4i> >>> <https://marketplace.microsoft.com/en-us/product/saas/ververica.vvc_managed?tab=Overview> >>> >>> Pflichtangaben/Mandatory Information >>> <https://www.ververica.com/mandatory-information> > > > > -- > Lorenzo Affetti > Senior Software Engineer @ Flink Team > Ververica
