Hey Guarav, Thanks for your proposal.
> disruptive, full-cluster restart, posing significant risks in live > environments For configuration that isn't hot-reloadable, like providing a new IAuthenticator implementation, a rolling restart is required. But rolling restarts are zero-downtime and safe in production, as long as you pace them accordingly. In general, changing authenticators is a risky thing because it requires coordination with clients. To mitigate this risk and support clients while they transition between authenticators, I like the approach taken by MutualTlsWithPasswordFallbackAuthenticator: https://github.com/apache/cassandra/blob/bec6bfde1f3b6a782f123f9f9ff18072a97e379f/src/java/org/apache/cassandra/auth/MutualTlsWithPasswordFallbackAuthenticator.java#L34 If client certificates are available, then use those, otherwise use the existing PasswordAuthenticator that clients are already using. The existing IAuthenticator interface supports this transitional behavior well. Your proposal to include a new configuration for auth_enforcement_flag doesn't clearly cover how to transition from one authenticator to another. It says: > Soft: Operates in a monitoring mode without enforcing authentication Most users use authentication today, so auth_enforcement_flag=Soft would allow unauthenticated clients to connect to the database. -- Abe > On Feb 12, 2024, at 2:44 PM, Gaurav Agarwal <gaurav.iit...@gmail.com> wrote: > > Dear Cassandra Community, > > I'm excited to share a proposal for a new feature that I believe would > significantly enhance the platform's security and operational flexibility: a > flexible authentication mechanism implemented through a feature flag . > > Currently, enforcing authentication in Cassandra requires a disruptive, > full-cluster restart, posing significant risks in live environments. My > proposal, the auth_enforcement_flag, addresses this challenge by offering > three modes: > > Hard: Enforces strict authentication with detailed logging. > Soft: Monitors connection attempts (valid and invalid) without enforcing > authentication. > None: Maintains the current Cassandra behavior. > > This flag enables: > Minimized downtime: Seamless authentication rollout without service > interruptions. > Enhanced security: Detailed logs for improved threat detection and > troubleshooting. > Gradual adoption: Phased implementation with real-world feedback integration. > > I believe this feature provides substantial benefits for both users and > administrators. Please see the detailed proposal here: Introducing flexible > authentication mechanism > <https://docs.google.com/document/d/1w649JAJdhVNQwQ9btXaaUopXlGjia6Sfgv281U9U7HY> > > I warmly invite the community to review this proposal and share your valuable > feedback. I'm eager to discuss its potential impact and collaborate on making > Cassandra even better. > > Thank you for your time and consideration. > > Sincerely, > Gaurav Agarwal > Software Engineer at Uber
