Hi Lorenzo and all, I think this proposal is also solid and after addressing any open comments we can start the Vote.
Best, Giannis On Sun, 28 Jun 2026 at 4:40 AM, Forward Xu <[email protected]> wrote: > Hi Lorenzo, > > Thanks for driving this FIP — adding TLS/mTLS support is an important step > for running Fluss in shared, cloud, and multi-tenant environments, so big > +1 from me on the direction. > > I'd also like to echo the two points Giannis raised, as I think they're > worth addressing explicitly in the proposal: > > 1. > > *Zero-copy trade-off.* Since Netty's SslHandler can't encrypt a > FileRegion, enabling TLS effectively means losing the zero-copy path. It > would be great to call this out explicitly in the FIP so users > understand > the performance trade-off when turning TLS on, and to clarify whether it > applies only to TLS-enabled listeners (so plaintext internal paths can > keep > zero-copy). > 2. > > *Credential lifetime.* Like Giannis, I'd find it helpful to know whether > the design assumes short-lived credentials, or whether certificate > rotation > / revocation (CRL/OCSP) is left to the operator's PKI. > > Overall this looks solid to me. Thanks again for the work! > > Best, ForwardXu > > Anton Borisov <[email protected]> 于2026年6月26日周五 18:57写道： > > > 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 > > >
