Hi,
I think what Gaurav means is what we know at DataStax as transitional
authenticator, which temporarily allows for partially enabled
authentication - when the system allows the clients to authenticate but
does not enforce it.
All in all, that should be included in CEP-31 - also CEP-31 aims to
Auth is one of those things that needs to be a bit more concrete In the scenario you describe, you already have an option to deploy the auth in piece partially during the rollout (pause halfway through) in the cluster and look for asymmetric connections, and the option to drop in a new Authenticato
Dear Dinesh and Abe,
Thank you for reviewing the document on enabling Cassandra authentication.
I apologize that I didn't initially include the following failure scenarios
where this feature could be particularly beneficial (I've included them
now):
*Below are the failure scenarios:*
- Incorr
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.
>
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
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 r
