It's best-practice to disable the default user ("cassandra" user) after
enabling password authentication on your cluster. The default user reads
with a CL.QUORUM when authenticating, while other users use CL.LOCAL_ONE.
This means it's more likely you could experience authentication issues,
even if you increase the replication factor of your system_auth keyspace.
See the docs for more info:
http://cassandra.apache.org/doc/latest/operating/security.html#enabling-password-authentication

Also, accessing Cassandra via a load-balancer is considered an
anti-pattern. The Cassandra drivers load-balance requests to the cluster
transparently, so the only thing you get by adding a load balancer to the
mix is potentially increased query latency.

Cheers,
Justin


On Fri, 7 Jul 2017 at 21:42 Oleksandr Shulgin <oleksandr.shul...@zalando.de>
wrote:

> On Thu, Jul 6, 2017 at 6:58 PM, Charulata Sharma (charshar) <
> chars...@cisco.com> wrote:
>
>> Hi,
>>
>> I am facing similar issues with SYSTEM_AUTH keyspace and wanted to know
>> the implication of disabling the "*cassandra*" superuser.
>>
>
> Unless you have scheduled any tasks that require the user with that name
> to be there, there are no implications.  This user is not used by Cassandra
> tools or the server process internally, so nothing really depends on it.
>
> Of course, in order to drop a superuser account, you need to create
> another superuser, so in the end you still have superuser access to your
> cluster.
>
> Cheers,
> --
> Alex
>
> --


*Justin Cameron*Senior Software Engineer


<https://www.instaclustr.com/>


This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.

Reply via email to