Support Forums : DataStax

DataStax Support Forums » Apache Cassandra

Cassandra security features

(7 posts) (3 voices)

Started 10 months ago by singh.ajay1983
Latest reply from mbulman
This topic is not a support question

Tags:

singh.ajay1983
Member

Hi All,

Are there plans to improve Cassandra security features in the coming releases? The present authentication and authorization mechanism is file based (as of 1.0) and is of limited use. We need features like adding/removing users dynamically through client APIs and CQL. We also need dynamic control over authorization.

Thanks
Ajay

Posted 10 months ago #
xedin
Member

Yeah, there are few plans to add stronger authentication/authorization schemes to the DSE currently in review and probably Cassandra native authorization scheme compatibile with CQL in upcoming 1.3 (or if time would be sufficient in 1.2) release.

Posted 10 months ago #
singh.ajay1983
Member

Thanks Xedin. Is there a jira tracker for this ? I want to get some idea about the security features which are being discussed. It will help me take a decision on the authentication/authorization aspect of my project.

Posted 10 months ago #
xedin
Member

There are no tickets yet but you are welcome to create one to draw attention to the problem, currently the way out for you is to implement IAuthority and IAuthenticator interfaces and replace default ones in the conf/cassandra.yaml.

Posted 10 months ago #
mbulman
Key Master

Ajay,

We'd love to hear more about what types of improvements you're looking for. Would you prefer for everything to be internal to Cassandra/DSE, or have the ability to tie into an external system?

How granular would you need the authorization to be?

Posted 10 months ago #
singh.ajay1983
Member

Hi Mike,

We are working on a multi-tenant solution using Cassandra and would like to have a finer control on what each tenant can access. Initially, we were thinking of putting the required logic in the application layer using a separate database but it is good if Cassandra can handle most of it for us.

1. Dynamic creation/deletion of users using client APIs (thrift) and CQL.

2. Ability to perform authorization at keyspace, column family level (already there) and change it on the fly.

3. Ability to perform (dynamic) authorization at row-key level . In our case, we can have (related) rows which store same kind of data. So we have rows keys like X_Week1, X_Week2.... to store data related to X (it is time-series data). Great if we can specify an authorization setting like X_* to give access to all X data.

4. I guess this one is specific to our data model and I may be asking for too much here. Authorization at column name level and again ability to change this on the fly. If the column names are timestamps, I want to restrict data access based on the time. e.g. Give access for X (row keys with X_*) but only include the columns which fall in the range col_low - col_high. The output in this case will come from multiple rows.

I am not sure if I understand your other question 'internal to Cassandra/DSE vs having the ability to tie into an external system'. When you say external system do you mean a separate database and library to implement authentication/authorization and Cassandra using its services? I guess that would be better than making this whole thing reside in Cassandra.

Thanks
Ajay

Posted 10 months ago #
mbulman
Key Master

Thanks for the feedback, Ajay. When I say external, I mean tying into a system (eg, LDAP) that is responsible for storing user auth data -- as opposed to C*/DSE storing it internally.

Posted 10 months ago #

RSS feed for this topic

Reply

You must log in to post.