Hi Gaurav, Thank you for the document. I read through it and wasn't entirely clear about the problem you're trying to solve.
If you're talking about enabling authentication for the very first time on a cluster which does not have any authentication then there are different ways of handling it. > Minimized downtime: Seamless authentication rollout without service interruptions. I am not sure why would the app or the cluster take any downtime as rolling restarts in Cassandra are safe and do not cause downtime. If Cassandra doesn't require authentication, specifying credentials in the driver should not cause issues. So users are safe to transition from an unauthenticated to an authenticated cluster. > Enhanced security: Detailed logs for improved threat detection and troubleshooting. Allowing client connections to proceed with invalid credentials poses a serious security risk. Cassandra 4.0+ has Audit Logging which IIRC does log invalid login attempts (if not, it would be trivial to add them). CASSANDRA-11471 allows for improved protocol negotiation which would allow you to specify a list of acceptable authentication mechanisms but I don't think this is being worked on at the moment. That said, right now you can certainly implement your own Authenticator which implements your custom logic without any changes to Cassandra itself. Dinesh On Mon, Feb 12, 2024 at 11:45 AM 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 >
