If you wanted to use Riak in a secure fashion in versions prior to 2.0, your only option was to do so at the network level, using a firewall or similar protective layer. While this is sufficient for a lot of use cases, the problem with this form of security is that if someone can penetrate the firewall, they essentially have unrestricted access to a Riak cluster. They can perform reads and writes, run MapReduce jobs, you name it.
In Riak version 2.0, this is changing in dramatic fashion. While you can still apply a network security layer if you wish, Riak now comes with security features that protect Riak itself and not just to the network in which it's housed. Most importantly, in Riak 2.0 you can both authorize users to perform specific tasks (from standard read/write/delete operations to search queries to managing bucket types) and authenticate users and clients using a variety of security mechanisms.
In other words, if you're using Riak Security, then Riak needs to know who a connecting client is and what that client is allowed to do.
Let's say that you've decided to deploy Riak in production and you want to use Riak Security from the very get-go. This section will walk you through how to go from a fresh Riak installation with no security whatsoever to creating users, managing roles, applying security sources, the whole deal.
This walk-through assumes that you've already installed Riak 2.0 and have a cluster up and running. If you haven't, first download Riak, install it, and stand up a cluster in your local development environment.
Once Riak is up and going, cd into your installation. In the /bin directory for each node, you'll see that there's a riak-admin command. You can run that command via the /bin directory (in any running node) or alias the command to use it anywhere on your system. All of Riak Security's CLI functionality is available through the riak-admin security command.
At first, all the gates to your Riak cluster are completely open. Anyone can run any conceivable Riak operation on this cluster as long as they know the host/port and know how to use HTTP and/or protocol buffers to interact with Riak. But with one command, we can change that:
riak-admin security enableIf you run that command and get no response, then security has been successfully enabled on your cluster. Now, nobody can do anything with this cluster. No one can read or write keys, no one can run MapReduce jobs, no one can change bucket properties, etc. Riak is now an absolute fortress.
It's also important to note that enabling security will fundamentally change the way that your client(s) interact with Riak. All connections must be encrypted and all permissions will be denied to all clients and users by default.
While making Riak into a fortress might relieve some anxiety, you can't really do anything with it. So let's start selectively enabling access to all the goodness and plenty that Riak has to offer.
The first thing we'll do is create an admin role that enables anyone in that role to do whatever they'd like with Riak as long as they can identify themselves as having that role. We can use the add-user command for that:
riak-admin security add-user adminThis creates the admin user/role, but anyone occupying this role can't actually do anything yet because we need to grant permissions to that role first. We'll start by enabling admins to run basic reads and writes on any bucket of any bucket type (riak_kv.get and riak_kv.put respectively):
riak-admin security grant riak_kv.get,riak_kv.put ON ANY TO adminNow, anyone who's an admin user is authorized to make read and write requests.
But those users still can't actually perform those operations because we've specified what those users are authorized to do but we haven't specified how they'll be authenticated---we haven't yet designated our cluster's security sources.
Riak Security in 2.0 provides four options for security sources:
trust--- Any user accessing Riak from a specified IP may perform the permitted operationspassword--- Authenticate with username and password (works essentially like basic auth)pam--- Authenticate using a pluggable authentication module (PAM)certificate--- Authenticate using certificates (e.g. SSL)
In this tutorial, we'll use username/password as a security source for the sake of simplicity. We'll specify that any user with the role admin who is accessing Riak on localhost can make reads and writes:
riak-admin security add-source admin 127.0.0.1/32 passwordWhen we created our admin role, we didn't specify a password. We can change that using the alter-user command. Let's assign the password riakmaster to the admin user:
riak-admin security alter-user admin password=riakmasterSo now we've created an admin user/role, granted permissions, and specified a security source (password). Let's try to access Riak using the HTTPS interface (we have to use [SSL](link to future SSL tutorial) because Riak does not accept credentials of any kind over HTTP).
We'll run a simple GET request on the key test_key in the bucket test_bucket, which will simply bear the default type, passing in the username and password:
curl -u admin:riakmaster https://127.0.0.1:10018/types/default/buckets/test_bucket/keys/test_key
If our security has been appropriately set up, this should return a simple not found, as we have you to store any data in our empty yet secure Riak cluster. Let's fix that:
curl -XPUT \
-H "Content-Type: text/plain" \
-d "hello from inside fortress Riak" \
-u admin:riakmaster \
https://127.0.0.1:10018/types/default/buckets/test_bucket/keys/message
That will return a response like this:
HTTP/1.1 200 OK
X-Riak-Vclock: a85hYGBgzGDKBVIcR4M2cgczH7HPYEpkzGNlWHSq7gxfFgA=
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Link: </buckets/test_bucket>; rel="up"
Last-Modified: Sun, 23 Feb 2014 19:40:18 GMT
ETag: "7TUHUoxFAtXa9qy1AiMXIH"
Date: Sun, 23 Feb 2014 19:40:33 GMT
Content-Type: text/plain
Content-Length: 5
hello from inside fortress Riak%
And there it is: a secure message from Riak.
More extensive information is available in our Authentication and Authorization tutorial. With the new security features, you can require that all clients connecting to Riak authenticate themselves using certificates, provide access to specific buckets or bucket types only to some clients and not others, create users that are only allowed to run MapReduce jobs, and so on.
While some features, such as encryption of data at rest, have not made it into the 2.0 release, we feel that the changes introduced in version 2.0 are a strong initial step in the right direction.