Using OpenStack Object Storage ACLs

Access Control Lists (ACLs) allow us to have greater control over individual objects and containers without requiring full read/write access to a particular container. With ACLs, you can expose containers globally or restrict them to individual tenants and users.

Getting ready

Ensure you are logged in to a Ubuntu host that has access to our OpenStack environment on the 192.168.100.0/24 public network. This host will be used to run client tools against the OpenStack environment created. If you are using the accompanying Vagrant environment, as described in the Preface, you can use the controller node. It has the python-swiftclient package installed that provides the swift command-line client.

If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller

Ensure you have set the following credentials (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

How to do it...

Carry out the following steps:

  1. We will first create an account in our OpenStack Identity Server that is only a Member in the cookbook tenant. We will call this user user. The code is as follows:
    export ENDPOINT=192.168.100.200
export SERVICE_TOKEN=ADMIN
export SERVICE_ENDPOINT=https://${ENDPOINT}:35357/v2.0
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

# First get TENANT_ID related to our 'cookbook' tenant
TENANT_ID=$(keystone tenant-list 
    | awk ' / cookbook / {print $2}')

# We then create the user specifying the TENANT_ID 
keystone user-create 
    --name test_user 
    --tenant_id $TENANT_ID 
    --pass openstack 
    --email user@localhost 
    --enabled true

# We get this new user's ID
USER_ID=$(keystone user-list | awk ' / user / {print $2}')

# We get the ID of the 'Member' role
ROLE_ID=$(keystone role-list 
    | awk ' / Member / {print $2}')

# Finally add the user to the 'Member' role in cookbook 
keystone user-role-add 
    --user $USER_ID 
    --role $ROLE_ID 
    --tenant_id $TENANT_ID
  2. After creating our new user, we will now create a container using a user that has admin privileges (and therefore a container that our new user initially doesn't have access to), as follows:
    swift post testACL
  3. We will then set this container to be read-only for our user named test_user:
    swift post –r test_user testACL
  4. We will upload a file to this container using our new user:
    swift upload testACL /tmp/test/test1

    This brings back an "HTTP 403 Forbidden" message similar like this:

    Object HEAD failed: https://proxy-server:8080/v1/AUTH_53d87d9b66794904aa2c84c17274392b/testACL/tmp/test/test1 403 Forbidden
  5. We will now give write access to the testACL container for our user by allowing write access to the container:
    swift post –w test_user –r test_user testACL
  6. When we try to upload the file again, it is successful:
    swift upload testACL /tmp/test/test1

How it works

Granting access control is done on a container basis and is achieved at the user level. When a user creates a container, other users can be granted that access by adding them to the container. The users will then be granted read and write access to containers, for example:

swift post -w user -r user container
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset