Riak security

Aphyr aphyr at aphyr.com
Fri Sep 30 15:00:30 EDT 2011

We've been over this several times on riak-users, which suggests to me a 
blog post might help. I'll try to draft something.

On 09/30/2011 11:00 AM, Kyle Quest wrote:
> This is a pretty common situation with the NoSQL databases. They have
> no security and the standard answer is that it's your job to do with
> firewalls and proxies. This is a good indication that the NoSQL world
> is still in its infancy. Security features will get there eventually
> and Accumulo is an example of progress in terms of security
> capabilities, but it's going to take a while... a long while :-)

If you have a sensible, flexible, comprehensive proposal for access 
control in an eventually consistent distributed key-value store, I would 
love to hear about it. Thus far, every attempt I've encountered rapidly 
approaches the proverbial "blatant layering violation", or is a subset 
of {inconsistent, inadequate, overly specific, complex, slow}.

Accumulo (IIUC, docs are scarce) tags data with authorizations; 
restricting access is up to the client. You can do that in Riak. You can 
front Riak with a layer which allows puts/gets (globally, to buckets, to 
keys, at various times, etc.) on the basis of HTTP auth, sessions, IP, 
certificate, etc. You can also implement access control by writing valid 
state transitions on an object to a statebox and invalidating concurrent 
modifications that introduce policy conflicts. Authentication provided 
by cryptographic hashes on transitions, or by a layer above. You could 
introduce a lock service and use it to enforce certain classes of 
sequential access, simplifying consistency.

Hopefully this suggests why it's not as simple as "adding security to 
the database". There are a wide variety of security semantics, and many 
can be layered on top of Riak (or any other datastore) without changing 
the database itself.

> Now in this case you can do something :-) One option is to use a web
> proxy that would expose two different ports for GET and PUT requests
> and then have the appropriate HTTP method filters for each of those
> ports.

Writes require reads beforehand, but this will do the trick.

> However, this doesn't really do much for security because these
> GET and PUT requests will still be sent to the same Riak node.


> A better solution is to have separate Riak nodes for reads and writes.

Riak forwards requests to the appropriate vnode for a key. Doing this 
would have no effect on operational semantics.


More information about the riak-users mailing list