Bucket ACLs?

Kevin Smith ksmith at basho.com
Thu Feb 4 10:50:21 EST 2010


We've got some ideas on implementing security to deliver exactly what you describe. But (and there's always a but) it's down our roadmap a bit as we have a number of other features taking priority first.

Having said that, it's been my experience as a developer that database permissions are not actually all that useful as an application permissions model. I've normally stored application permissions in the database and then queried that information to determine access for application users. A similar model would work as well on top of Riak.

--Kevin
On Feb 4, 2010, at 10:26 AM, Timothy Perrett wrote:

> Sure - that was my other thought; having some common library that handled the auth. Probably wouldn't be my first choice however as quite often "data" users are different to users in my problem domain. 
> 
> Anyway... any plans to implement some kind of "bucket group permissions" or whatever? For now it seems separate instances is the way to go right? 
> 
> Cheers!, Tim
> 
> On 4 Feb 2010, at 14:58, Kevin Smith wrote:
> 
>> The other option is to enforce the security within your application logic. Riak doesn't have ACLs so it has to rely on external components to enforce security policy.
>> 
>> I agree ACLs would be a useful feature but Riak doesn't have them right now.
>> 
>> --Kevin
>> On Feb 4, 2010, at 9:49 AM, Timothy Perrett wrote:
>> 
>>> Certainly managing security / ACLs with the front end proxy is far from ideal.
>>> 
>>> I should have thought that quite a lot of Riak users would like to achieve this kind of setup right? Otherwise there is no real way to segregate your datasets.
>>> 
>>> Cheers, Tim
>>> 
>>> On 4 Feb 2010, at 13:00, Sean Cribbs wrote:
>>> 
>>>> Although it's probably not the best solution, you could definitely add those restrictions in a reverse-proxy, say with Apache or nginx in front of Riak.  Require your applications to authenticate with the front end, and then restrict their access accordingly.
>>>> 
>>>> There are definite uses for multiple clusters, but I think having a cluster per customer might not be the best solution, simply for the sake of the duplication of effort.  It depends on your application's needs of course.  For managing the cluster(s), I definitely recommend looking into a configuration management tool that can ease new deployments (Chef, Puppet, cfengine, etc) and then adding monitoring (monit, god, munin, nagios, etc).
>>>> 
>>>> Sean
>>>> 
>>>> On 2/4/10 7:33 AM, Timothy Perrett wrote:
>>>>> Hey all,
>>>>> 
>>>>> Whilst I appreciate there are "buckets" in Riak, how would one setup a situation where a customer only has access to Bucket A and B, whilst customer2 has access to buckets C, D and E. When I say customer, I really mean there systems, but I guess you get that :-)
>>>>> 
>>>>> If this is not possible, I presume different  Riak instances are the only way to go to keep that separation? If so, what is the best way of managing all these instances and what would be a memory foot print of such an instance?
>>>>> 
>>>>> Cheers, Tim
>>>>> _______________________________________________
>>>>> riak-users mailing list
>>>>> riak-users at lists.basho.com
>>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> riak-users mailing list
>>>> riak-users at lists.basho.com
>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>> 
>> 
> 





More information about the riak-users mailing list