Getting started with access control: CLI
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
- Creating a user
- Adding an SSH key to the user
- Creating a role to allow access to contractors
- Creating a policy that allows access to Manta objects
- Associating the policy with the role
- Associating the role with the object
- Finding out which roles are associated with an object
- The difference between members and default members in roles
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
- a login name
- a password
- an email address
$ 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 -