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>
