Hi Wang Chen, Yes, Kafka and Pulsar both support internal authentication, and we believe Fluss also should support the same. We're starting with client-server Kerberos auth first, and plan to add intra-cluster authentication (e.g., coordinator ↔ tablet) as future work, which will also be added in the proposal FIP-7.
Best regards, SeungMin Lee On 2025/07/21 05:43:28 Wang Cheng wrote: > Hi Lee, > > > How about authentication between the coordinator and tablet servers? Do we > have an intra-cluster membership encryption/authentication plan? > > > > Regards, > Cheng > > > > > > > > > ------------------ Original ------------------ > From: > "dev" > > <[email protected]>; > Date: Sun, Jul 20, 2025 03:49 PM > To: "dev"<[email protected]>; > > Subject: [DISCUSS] FIP-7: Support Kerberos Authentication via SASL/GSSAPI > > > > Hi all, > > Currently, Fluss supports SASL/PLAIN authentication and ACL-based > authorization, but lacks support for Kerberos-based authentication. This > makes it difficult for enterprises with existing Kerberos infrastructure to > adopt Fluss securely. > > This proposal introduces a new SASL mechanism, GSSAPI, to enable > Kerberos-based mutual authentication between Fluss clients and servers. The > implementation leverages Java's built-in GSSAPI and JAAS APIs to validate > Kerberos service tickets, and integrates with Fluss’s pluggable > authentication framework and ACL-based authorization layer. Only external > client-server communication is affected; internal RPCs (e.g., coordinator > <-> tablet server) remain unauthenticated by default. > > > This is my first FIP proposal, so any feedback, suggestions, or comments — > big or small — are truly welcome. > While I may not know all the answers immediately, I’ll do my best to study, > research, and respond thoughtfully. > > > [1]: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=373885589 > > Best regards, > SeungMin Lee
