Hi Lorenzo, Thanks for the FIP, I went through it and it feels solid. Direction makes sense to me: keeping TLS orthogonal to auth fits the per-listener plugin model and the SPI change is one backward-compatible method.
+1 to Giannis on zero-copy, and worth pinning down concretely. The fetch path uses sendfile today (FileRegionSend -> FlussFileRegion.transferTo -> FileChannel.transferTo), and SslHandler can't wrap a FileRegion, so TLS listeners fall back to copy-through-the-engine and lose zero-copy. Same trade-off Kafka makes with SSL. The OpenSSL provider (already future work) cuts the encryption CPU but doesn't bring sendfile back. Only kTLS does, and that's Linux-only + native transport + experimental in Netty, so I'd park it explicitly as out of scope rather than leave it implied. Either way, it is worth calling the throughput hit out in the FIP so operators aren't surprised. A few more things: 1. Config validation. security.ssl.enabled.listeners (transport) and security.protocol.map (auth) are set independently, but mTLS only works over TLS. A listener mapped to mTLS but left out of the SSL set starts clean, then every connection dies at AuthenticateRequest on a null sslSession(), which the FIP already documents. A config typo surfacing as a per-request runtime failure. Shall we validate at startup instead: mTLS listener must be SSL-enabled and have a truststore, TLS listener needs a keystore, client mTLS needs the SSL switch plus a keystore? Cheap, and it fails loud and early. 2. Observability vs the reload machinery. Metrics are deferred to logs; I'd pull two into v1. A handshake-failure counter and that's just matching Kafka, which exposes failed-authentication-total/-rate with SSL handshake failures counted. And a cert days-to-expiry gauge, which Kafka notably lacks, and that gap has taken clusters down (Strimzi had a proposal to add expiry monitoring, don't remember the status and if it's merged or not though), so worth shipping rather than repeating. Handshake failure is below the normal RPC error path, so logs-only is effectively invisible in prod. Meanwhile the reactive self-healing reload (content hashing, rate limiting) is heavier than anything Kafka ships - the auto-reload work there (KIP-687/KIP-1119) is just file-watch + interval, and the long-standing path is operator-triggered dynamic config. Shall we ship interval reload + those two metrics in v1 and defer the self-healer? WDYT? 3. Two clarifications. (a) The FIP secures RPC but says nothing about the server<->ZK connection, remote storage. Let's just say smth in Non-Goals, so we're not implying the cluster is end-to-end encrypted by default with this FIP implementation, but ZK/remote storage encryption is handled by their own mechanism. (b) SslPrincipalMapper is "Kafka-compatible" but v1 ships only DEFAULT + basic rules. A rule copied from a working Kafka config could map to the wrong principal silently - a silent authz failure, not just wasted work. Shall we fail-fast on rules we don't fully support rather than fall through? -- Anton пт, 19 июн. 2026 г. в 05:58, Giannis Polyzos <[email protected]>: > > 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 > > <https://www.google.com/maps/search/Herzogspitalstrasse+24+%7C+80331+M%C3%BCnchen+%7C+Germany?entry=gmail&source=g> > > > > 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> > >
