> > However, the actual keyspace (system_auth) and tables are not created > until the last node is restarted with the parameters changed
Actually, this is not strictly true. On 2.2+ the tables in system_auth are created up front, regardless of the auth config. Practically you can't go about setting up your roles until all nodes in the cluster are on 2.2 or higher, but if they are, then you can. 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). This is also not 100% accurate. Using a modern driver, your clients can be configured with credentials before the cluster requires them. Drivers will not send those credentials unless the server they're connecting to asks for them. So provided you modify your clients to begin sending credentials before turning authentication on you can enable it without downtime. The ugly part is that you need to enable auth on at least one node in order to set up the roles in the system. This is obviously racy as clients may start connecting to that node as soon as you've enabled authentication but before you've added all necessary roles. However, if you can stop clients connecting to that node (maybe via iptables), then you won't hit that problem. Once all the necessary roles and credentials are configured, you can re-enable client connections to it and enable authentication on the rest of the cluster in a rolling fashion (i.e. stop node, modify yaml, restart node) and you shouldn't encounter any downtime. This is now covered in the latest docs, which are targeted at 3.x but this in case they apply equally to 2.2. http://cassandra.apache.org/doc/latest/operating/security.html#authentication On Tue, Aug 2, 2016 at 5:21 PM, Jai <jaibheem...@gmail.com> wrote: > 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. >> > >
