Getting started with access control: CLI

Modified: 22 Nov 2017 17:38 UTC

In this walkthrough we'll demonstrate access control on Manta objects using the command line interface. If you haven't already, be sure to read the (RBAC overview, then come back here to continue.

To follow along you will need to install the CloudAPI and Manta CLI tools. See Getting the RBAC tools to learn how to set up your environment.

Overview

Assume that we have a contractor named Maria. We want to give her access to a single Manta object, access.log. In this walkthrough you will learn about

Once that's done, we'll modify the contractor role to allow Maria to access the entire directory.

There are two Manta objects in the account. The account owner always has unrestricted access to all the objects. All other users in the account need permission to access any objects.

$ mls ~~/stor
access.log
readme.txt

$ mget -q ~~/stor/access.log | head
127.0.0.1 - - [11/Feb/2014:13:31:11 -0500] "GET / HTTP/1.1" 200 2158
127.0.0.1 - - [11/Feb/2014:13:31:18 -0500] "GET /search?q=linux HTTP/1.1" 200 2580
127.0.0.1 - - [11/Feb/2014:13:31:56 -0500] "GET /template HTTP/1.1" 200 7023
127.0.0.1 - - [11/Feb/2014:13:32:02 -0500] "GET /assets/images/upgrading HTTP/1.1" 200 5992
127.0.0.1 - - [11/Feb/2014:13:32:10 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/styles.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/php.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/html.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/js.css HTTP/1.1" 304 -

Create a user

Now, create the user maria. When you create a user, you must provide

$ sdc-user create --login=maria --password=123secret --email=maria@example.com
{
  "id": "8e9fcc58-3240-4e33-d145-fad9d92c6822",
  "login": "maria",
  "email": "maria@example.com",
  "updated": "2014-07-17T15:32:48.029Z",
  "created": "2014-07-17T15:32:48.029Z"
}

You can learn more about users in Working with users.

Add an SSH key to the user

Every user needs an SSH key. Ideally, every user has their own SSH key.

$ sdc-user upload-key 8e9fcc58-3240-4e33-d145-fad9d92c6822 --name=mariakey ~/.ssh/maria.pub
{
  "name": "mariakey",
  "fingerprint": "61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04",
  "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLnrt...fMp maria@example.com\n"
}

The new user, maria, has no access by default. When she tries to list the Manta contents, she gets an error.

$ mls --user=maria --keyId=61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04 ~~/stor
mls: NoMatchingRoleTagError: None of your active roles are present on the resource.

Create a role

We want to give Maria access to the object access.log. First, create a role. We'll call it contractor, and make maria a member.

$ sdc-role create --name=contractor --members=maria --default-members=maria
{
  "name": "contractor",
  "id": "559d4252-d75c-4189-bf08-f30c73a703a6",
  "members": [
    "maria"
  ],
  "default_members": [
    "maria"
  ],
  "policies": []
}

Default members are users who can assume a role without specifying it. Users who are not default members need to specify the role when they access a resource.

You can learn more about roles in Working with roles.

The new role has no policies, so let's create that next.

Create a policy

A policy is a named collection of rules. Rules are written in the Aperture policy language , which allows you write rules in a human readable form. Aperture rules are of the form

CAN <action> IF <condition>

For this walkthrough, we'll be using only two Manta actions, and we will not be using the condition part of the rule. See (Working with rules to learn more about writing rules.

Rule Description
CAN getobject Read a Manta object
CAN getdirectory List a Manta directory

We now create a new policy named read. It has one rule that allows a user to get a Manta object.

$ sdc-policy create --name=read --rules='CAN getobject'
{
  "name": "read",
  "id": "3072e003-34f7-c4a5-9f73-a8808de40e26",
  "rules": [
    "CAN getobject"
  ]
}

You can learn more about policies in Working with policies, and you can learn about the available rules in Working with rules.

Associate the policy with the role

Now we can add the read policy to the contractor role.

$ sdc-role update 559d4252-d75c-4189-bf08-f30c73a703a6 --policies=read
{
  "name": "contractor",
  "id": "559d4252-d75c-4189-bf08-f30c73a703a6",
  "members": [
    "maria"
  ],
  "default_members": [
    "maria"
  ],
  "policies": [
    "read"
  ]
}

Associate the role with the object

The final step is to associate the role with an object. For Manta objects, use the mchmod command.

$ mchmod +contractor  ~~/stor/access.log

Maria still can't list the contents of ~~/stor.

$ mls --user=maria --keyId=61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04 ~~/stor
mls: NoMatchingRoleTagError: None of your active roles are present on the resource.

But she can get the contents of access.log.

$ mget -q --user=maria --keyId=61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04 ~~/stor/access.log | head
127.0.0.1 - - [11/Feb/2014:13:31:11 -0500] "GET / HTTP/1.1" 200 2158
127.0.0.1 - - [11/Feb/2014:13:31:18 -0500] "GET /search?q=linux HTTP/1.1" 200 2580
127.0.0.1 - - [11/Feb/2014:13:31:56 -0500] "GET /template HTTP/1.1" 200 7023
127.0.0.1 - - [11/Feb/2014:13:32:02 -0500] "GET /assets/images/upgrading HTTP/1.1" 200 5992
127.0.0.1 - - [11/Feb/2014:13:32:10 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/styles.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/php.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/html.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/js.css HTTP/1.1" 304 -

Getting access information about an object

To find out which roles are associated with a Manta object, use the minfo command.

$ minfo ~~/stor/access.log
HTTP/1.1 200 OK
etag: b08c37e1-2878-c45a-8858-840810d5fe88
last-modified: Thu, 17 Jul 2014 15:46:15 GMT
role-tag: contractor
durability-level: 2
content-length: 495222
content-md5: ZJMsN0NiqW15Tbih7yKKlg==
content-type: text/plain
date: Thu, 17 Jul 2014 16:10:17 GMT
server: Manta
x-request-id: 0c2f74a9-1263-4654-89b0-4031206343b2
x-response-time: 27
x-server-name: 204ac483-7e7e-4083-9ea2-c9ea22f459fd
connection: keep-alive

Adding a new policy to a role

We want to let Maria list the contents of ~~/stor, so we create a new policy named list that allows access to directory contents.

$ sdc-policy create --name=list --rules='CAN getdirectory'
{
  "name": "list",
  "id": "616b8f9b-9260-e34d-fcbf-f6dba02a6512",
  "rules": [
    "CAN getdirectory"
  ]
}

Now we add the list policy to the contractor role. You have to name all the policies. sdc-role update replaces the existing policies with the ones you specify.

$ sdc-role update 559d4252-d75c-4189-bf08-f30c73a703a6 --policies=list --policies=read
{
  "name": "contractor",
  "id": "559d4252-d75c-4189-bf08-f30c73a703a6",
  "members": [
    "maria"
  ],
  "default_members": [
    "maria"
  ],
  "policies": [
    "read",
    "list"
  ]
}

We have to associate the contractor role with ~~/stor.

$ mchmod +contractor ~~/stor

Now Maria can list the entire directory, but she only has access to access.log.

$ mls --user=maria --keyId=61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04 ~~/stor
access.log
readme.txt

$ mget -q --user=maria --keyId=61:62:35:66:e6:e0:91:6a:fc:dc:d2:1b:90:52:51:04 ~~/stor/readme.txt
mget: NoMatchingRoleTagError: None of your active roles are present on the resource.

Members vs default members

A role has two lists of members. The default members list are users who assume the role automatically. Users on the members list must specify the role explicitly.

For example, we add the user jill to the contractors member list but not to the default members list.

$ sdc-role update 559d4252-d75c-4189-bf08-f30c73a703a6 --members=maria --members=jill
{
  "name": "contractor",
  "id": "559d4252-d75c-4189-bf08-f30c73a703a6",
  "members": [
    "maria",
    "jill"
  ],
  "default_members": [
    "maria"
  ],
  "policies": [
    "read",
    "list"
  ]
}

Now if Jill tries to get access.log, she gets an error.

$ mget -q --user=jill --keyId=10:d0:59:ef:4f:71:3b:8b:4b:6a:05:d2:57:24:28:27 ~~/stor/access.log | head
mget: NoMatchingRoleTagError: None of your active roles are present on the resource.

But if she explicitly assumes the contractor role, she can read the object.

$ mget -q --role=contractor --user=jill --keyId=10:d0:59:ef:4f:71:3b:8b:4b:6a:05:d2:57:24:28:27 ~~/stor/access.log | head
127.0.0.1 - - [11/Feb/2014:13:31:11 -0500] "GET / HTTP/1.1" 200 2158
127.0.0.1 - - [11/Feb/2014:13:31:18 -0500] "GET /search?q=linux HTTP/1.1" 200 2580
127.0.0.1 - - [11/Feb/2014:13:31:56 -0500] "GET /template HTTP/1.1" 200 7023
127.0.0.1 - - [11/Feb/2014:13:32:02 -0500] "GET /assets/images/upgrading HTTP/1.1" 200 5992
127.0.0.1 - - [11/Feb/2014:13:32:10 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/images/search?q=linux HTTP/1.1" 404 1760
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/styles.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/php.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/html.css HTTP/1.1" 304 -
127.0.0.1 - - [11/Feb/2014:13:32:11 -0500] "GET /assets/styles/js.css HTTP/1.1" 304 -