Joyent Manta RBAC, breaking it down


One of my jobs at ComplyMD is managing the operations side of things. We're looking for help if you're interested! We have a nice little setup for User Acceptance Testing and staging that ties Docker together with Github and our ticketing system (JIRA). For a myriad of reasons, we're currently migrating our testing environment from a Linode/local hardware hybrid to the nice people at Joyent.

I was poking around with Manta, which is Joyent's powerful object storage service (think S3 on sterioids), and was curious how the access control worked. As it turns out, the policies and roles work quite differently than expected, probably mostly to do with my familiarity with Amazon S3.

Getting Started

Joyent's docs are pretty helpful, but I thought I might be able to digest them a bit better for some readers, as a few folks on IRC requested. I was able to glean most of how to do this from Joyent's own Getting Started page, which I suggest you read and perform the prerequisites to before proceeding (primarily getting the various keys, environment variables, and tools setup properly).


The stor folder in Manta is only accessible to the master account, and is locked down to all other users by default. I wanted a place in stor that my test environment could store things for use in my custom images.


We'll need quite a few things to make this work:

  1. Subuser testing
  2. Policies read and write
  3. Role testing-access, consisting of policies read and write

Subuser Creation

Before we go down the long road of polcies and roles, we need to make sure we have a properly configured user. This can all be done with the GUI, but I find the CLI interface to be much more usable.

First, create the user.

sdc-user create --login=testing --password=yourpasswordhere [email protected]

Take note of the id returned, you will need it later. Once you have the user, you need to assign a public key for it. I recommend generating a new one with ssh-keygen, but you may use an existing one as well.

sdc-user upload-key 97d20c3e-0ed7-46f3-bedd-f00fe39f2c36 --name=testingkey ~/.ssh/

Take note of the fingerprint that is returned, you will use this later for your user's MANTA_KEY_ID environment variable (or --keyId argument to the CLI tools)


Policies are the core building blocks to Joyent's RBAC solution, and are written in Joyent's Aperture language. For our purposes we're just going to create some simple Manta policies.

Let's create a read policy that will allow us to read objects and list directory contents

sdc-policy create --name=read --rules='CAN getobject AND getdirectory'

Now that we've got a read policy, let's go ahead and create a write policy as well. This will let us create objects and directories.

sdc-policy create --name=write --rules='CAN putobject AND putdirectory'

That's it! We just created the two most basic building blocks of access control. There are a lot more permissions that are able to be used in policies fully described here.

Role creation

Ok, now it's time to get our role on. Roles are a key concept when it comes to Manta access control, because access to objects is controlled by Role Tags. If you're familiar with UNIX file permissions, Role Tags are basically like groups, but you can assign multiple to an object or directory.

Enough talk! Let's create our role. The below command creates a role with our read and write policies and adds our testing user to the members AND default_members list. It's important to note the difference between members and default_members. members can specify this role, while default_members have it applied by default.

sdc-role create --name=testing-access --members=testing --default-members=testing --policies=read --policies=write

If all goes well you should get something like this

  "name": "testing-access",
  "id": "a96a48cd-f6f4-4167-85e5-c71dfbe67716",
  "members": [
  "default_members": [
  "policies": [


At this point we have everything we need to use RBAC with Manta. We created a user with their own personal SSH key. Then we made policies to allow reading and writing of objects. Finally, we tied it all together by creating a role with our policies that has our user defined as a member and default_member.

Using mchmod

If you haven't already, create our testing directory by running

mmkdir ~~/stor/testing

as the master user. Once we have that, all that is left is to add our role to the role tags for the directory using mchmod

mchmod +testing-access ~~/stor/testing

At this point, your testing user should be able to run mls ~~/testing successfully with no errors. Since there is nothing there yet, let's try writing to it.

echo "test file" | mput ~~/stor/testing/testfile.txt

Now if you run our mls command again, you should see testfile.txt appear.