I have done it in production without downtime on apache cassandra by manipulating the user creation using iptables on first node.
Sent from my iPhone > On Aug 2, 2016, at 9:11 PM, DuyHai Doan <doanduy...@gmail.com> wrote: > > Thank you Sean for the excellent and details explanation, a lot of people out > there start their Cassandra in production without security and wake up some > days, too late > >> On Wed, Apr 13, 2016 at 10:54 PM, <sean_r_dur...@homedepot.com> wrote: >> Do the clients already send the credentials? That is the first thing to >> address. >> >> >> >> Setting up a cluster for authentication (and authorization) requires a >> restart with the properties turned on in cassandra.yaml. However, the actual >> keyspace (system_auth) and tables are not created until the last node is >> restarted with the parameters changed. So, as you are changing each node, >> what you get is individual nodes that are requiring a password, but have no >> system_auth keyspace to authenticate against. Thus, clients cannot connect >> to these nodes. >> >> >> >> With open source Cassandra you cannot implement authentication without at >> least a brief degradation of service (as nodes can’t authenticate) and an >> outage (while the keyspace and tables are created, users are created, and >> permissions are granted). The outage can be relatively brief, depending on >> cluster size, CL, speed to restart, etc. >> >> >> >> With DataStax Enterprise, there is a TransitionalAuthenticator (and >> Authorizer) that lets you implement security without a full outage. You >> basically switch to the Transitional classes so that system_auth gets >> created. You create all your security objects. Then you switch to >> PasswordAuthenticator and CassandraAuthorizer. It takes two rolling bounces >> to get it done, but no outage. >> >> >> >> I have done both of the above. The DataStax stuff is very helpful, when >> downtime is a concern. Perhaps you could write your own implementation of >> the various interfaces to do something like TransitionalAuthenticator, but >> we have seen that the security interfaces change, so you will probably >> break/rewrite in later versions. (For one-time use, maybe it is worth a >> shot?) >> >> >> >> For anyone setting up new clusters, just start with security turned on so >> that you don’t end up in the It’s-Production-Can’t-Stop quandary above. >> >> >> >> >> >> Sean Durity >> >> >> >> From: Vigneshwaran [mailto:vigneshwaran2...@gmail.com] >> Sent: Wednesday, April 13, 2016 3:36 AM >> To: user@cassandra.apache.org >> Subject: Set up authentication on a live production cluster >> >> >> >> Hi, >> >> >> >> I have setup a 16 node cluster (8 per DC; C* 2.2.4) up and running in our >> production setup. We use Datastax Java driver 2.1.8. >> >> >> >> I would like to set up Authentication and Authorization in the cluster >> without breaking the live clients. >> >> >> >> From the references I found by googling, I can setup credentials for a new >> cluster. But it is not clear to me what steps I should take for setting up >> credentials in an already running cluster without breaking existing clients. >> >> >> >> Can someone clarify me or link me to a reference I may have missed? I'd >> really appreciate it. >> >> >> >> Thank you, >> Vigneshwaran >> >> >> >> The information in this Internet Email is confidential and may be legally >> privileged. It is intended solely for the addressee. Access to this Email by >> anyone else is unauthorized. If you are not the intended recipient, any >> disclosure, copying, distribution or any action taken or omitted to be taken >> in reliance on it, is prohibited and may be unlawful. When addressed to our >> clients any opinions or advice contained in this Email are subject to the >> terms and conditions expressed in any applicable governing The Home Depot >> terms of business or client engagement letter. The Home Depot disclaims all >> responsibility and liability for the accuracy and content of this attachment >> and for any damages or losses arising from any inaccuracies, errors, >> viruses, e.g., worms, trojan horses, etc., or other items of a destructive >> nature, which may be contained in this attachment and shall not be liable >> for direct, indirect, consequential or special damages in connection with >> this e-mail message or its attachment. >
