How to share private container from object storage to another user on CREODIAS

You can create your own private containers in Object Store of your projects and you can grant access to other users.

If you want to limit the access for chosen users to specific containers, the other users have to be the members of other projects (it is recommended one user or group of users per one project).

The project can be in one or more domains.

Otherwise, if users are members of the same project, they see all containers in that project and you cannot limit access to specific containers.

Prerequisites

No. 1 Hosting

You need a CREODIAS hosting account with Horizon interface https://horizon.cloudferro.com.

No. 2 OpenStack client installed and connected to the cloud

The following article will help you install Python and OpenStack client called openstack and will also help you connect to the cloud How to install OpenStackClient for Linux on CREODIAS).

No. 3 Knowledge of downloading and working with RC files

To be able to share private containers, you will have to manipulate RC files from the cloud. The following article will provide technical details:

How to activate OpenStack CLI access to CREODIAS cloud using one- or two-factor authentication.

No. 4. Using OpenStack Swift module

The OpenStack Object Store module, known as Swift, allows you to store and retrieve data with a simple API. It’s built for scale and is optimized for durability, availability, and concurrency across the entire data set. Swift is ideal for storing unstructured data that can grow without bound.

Assuming that the openstack command is fully operational, install swift module:

$ pip install python-swiftclient # install python swift client

Read more about OpenStack Swift commands here.

Setting up the test example

In the example below there are three projects…

  1. “main”,

  2. “project_1”,

  3. “project_2”.

../_images/projects.png

… and three users:

  1. “owner” - the user with _member_ role in project “main”,

  2. “user_1” - the user with _member_ role in project “project_1”,

  3. “user_2” - the user with _member_ role in project “project_2”.

../_images/users.png

The user “owner” has three containers in their project “main”…

  1. c-main-a,

  2. c-main-b,

  3. c-main-d.

../_images/owner_con.png

…and the following files in the containers:

  • c-main-a

    • test-main-a1.txt

    • test-main-a2.txt

  • c-main-b

    • test-main-b.txt

  • c-main-d

    • test-main-d.txt

In the example below the user “owner” will grant “read only” access to container “c-main-a” for “user_1”

Download the RC file to share permissions with users

Firstly, the user “owner” should login to their domain if they didn’t do it yet:

../_images/owner_login.png

Then, they should choose the main project:

../_images/owner_main.png

After that, they should download the “OpenStack RC File” for the user “owner” and the project “main”:

../_images/owner_rc.png

Note

We shall assume the simplest case in which all three users have access to the cloud with one-factor authentication. If two-factor authentication is enabled, then the owner will have to share the six-digit code that is needed for the second factor of authentication.

You can preview the content of that file in your Linux terminal:

$ cat main-openrc.sh

main-openrc.sh

#!/usr/bin/env bash
# To use an OpenStack cloud you need to authenticate against the Identity
# service named keystone, which returns a **Token** and **Service Catalog**.
# The catalog contains the endpoints for all services the user/tenant has
# access to - such as Compute, Image Service, Identity, Object Storage, Block
# Storage, and Networking (code-named nova, glance, keystone, swift,
# cinder, and neutron).
#
# *NOTE*: Using the 3 *Identity API* does not necessarily mean any other
# OpenStack API is version 3. For example, your cloud provider may implement
# Image API v1.1, Block Storage API v2, and Compute API v2.0. OS_AUTH_URL is
# only for the Identity API served through keystone.
unset OS_TENANT_ID
unset OS_TENANT_NAME
export OS_AUTH_URL=https://keystone.cloudferro.com:5000/v3
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3
export OS_USERNAME="owner"
export OS_REGION_NAME="WAW3-1"
export OS_PROJECT_ID=ab0c8e1710854b92b0be2b40b31a615a
export OS_PROJECT_NAME="main_project"
export OS_PROJECT_DOMAIN_ID="119f4676f307434eaf28daab5ba3cc92"
if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi
if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi
if [ -z "$OS_PROJECT_DOMAIN_ID" ]; then unset OS_PROJECT_DOMAIN_ID; fi
echo "Please enter your OpenStack Password for project $OS_PROJECT_NAME as user $OS_USERNAME: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT
export OS_AUTH_TYPE=password
export OS_USER_DOMAIN_NAME="cloud_00373" # ****IF THIS LINE IS MISSING IN YOUR FILE PLEASE ADD IT!!!****

Sharing the RC file with the users

Copy the file main-openrc.sh to your CLI directory.

The user called “user_1” should do the same procedure:

  1. login to their “project_1”

  2. download the “OpenStack RC File” for user “user_1” and project “project_1”

project_1-openrc.sh

#!/usr/bin/env bash
# To use an OpenStack cloud you need to authenticate against the Identity
# service named keystone, which returns a **Token** and **Service Catalog**.
# The catalog contains the endpoints for all services the user/tenant has
# access to - such as Compute, Image Service, Identity, Object Storage, Block
# Storage, and Networking (code-named nova, glance, keystone, swift,
# cinder, and neutron).
#
# *NOTE*: Using the 3 *Identity API* does not necessarily mean any other
# OpenStack API is version 3. For example, your cloud provider may implement
# Image API v1.1, Block Storage API v2, and Compute API v2.0. OS_AUTH_URL is
# only for the Identity API served through keystone.
unset OS_TENANT_ID
unset OS_TENANT_NAME
export OS_AUTH_URL=https://keystone.cloudferro.com:5000/v3
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3
export OS_USERNAME="user_1"
export OS_REGION_NAME="WAW3-1"
export OS_PROJECT_ID=4d488c376c0b4bc79a60b56bc72834e8
export OS_PROJECT_NAME="p_project_1"
export OS_PROJECT_DOMAIN_ID="119f4676f307434eaf28daab5ba3cc92"
if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi
if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi
if [ -z "$OS_PROJECT_DOMAIN_ID" ]; then unset OS_PROJECT_DOMAIN_ID; fi
echo "Please enter your OpenStack Password for project $OS_PROJECT_NAME as user $OS_USERNAME: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT
export OS_AUTH_TYPE=password
export OS_USER_DOMAIN_NAME="cloud_00373" # ****IF THIS LINE IS MISSING IN YOUR FILE PLEASE ADD IT!!!****

The called “user_2” should do the same procedure as above.

Owner sources the RC file

Now, each user should open their terminal and source the openrc file:

terminal of user “owner”

$ source main-openrc.sh
Please enter your OpenStack Password for project main as user owner:  <here enter the password for owner>

(owner) $ swift list
c-main-a
c-main-b
c-main-d

User_1 sources the RC file

terminal of user “user_1”:

$ source project_1-openrc.sh
Please enter your OpenStack Password for project project_1 as user user_1:
 <here enter the password for user_1>

(user_1) $ swift list
c-project_1-a
c-project_1-b

User_2 sources the RC file

terminal of user “user_2”:

$ source project_2-openrc.sh
Please enter your OpenStack Password for project project_2 as user user_2: <here enter the password for user_2>

(user_2) $ swift list
c-project_2-a
c-project_2-b

Uploading of test files

The user “owner” prepares and uploads test files:

(owner) $ touch test-main-a1.txt
(owner) $ touch test-main-a2.txt
(owner) $ swift upload c-main-a test-main-a1.txt
test-main-a1.txt
(owner) $ swift upload c-main-a test-main-a2.txt
test-main-a2.txt
../_images/owner_upload_0.png 
(owner) $ touch test-main-b.txt
(owner) $ touch test-main-d.txt
(owner) $ swift upload c-main-b test-main-b.txt
test-main-b.txt
../_images/owner_upload_1.png 
(owner) $ swift upload c-main-d test-main-d.txt
test-main-d.txt
../_images/owner_upload_1.png

Check the id of user_1:

(user_1) $ openstack user show --format json "${OS_USERNAME}" | jq -r .id
3de5f40b4e6d433792ac387896729ec8

Check the id of user_2:

(user_2) $ openstack user show --format json "${OS_USERNAME}" | jq -r .id
fb4ec0de674d4c5ba608ee75cc6da918

You can check the status of the container “c-main-a”.

“Read ACL” and “Write ACL” are not set yet

(owner) $ swift stat c-main-a
                     Account: v1
                   Container: c-main-a
                     Objects: 2
                       Bytes: 29
                    Read ACL: *:3de5f40b4e6d433792ac387896729ec8
                   Write ACL: *:3de5f40b4e6d433792ac387896729ec8
                     Sync To:
                    Sync Key:
                 X-Timestamp: 1655199342.39064
X-Container-Bytes-Used-Actual: 8192
            X-Storage-Policy: default-placement
             X-Storage-Class: STANDARD
               Last-Modified: Tue, 14 Jun 2022 13:41:32 GMT
                  X-Trans-Id: tx000000000000003964e44-0062b17ebb-17404e6b-default
      X-Openstack-Request-Id: tx000000000000003964e44-0062b17ebb-17404e6b-default
               Accept-Ranges: bytes
                Content-Type: text/plain; charset=utf-8

Granting access

Grant access to container “c-main-a” for user_1:

(owner) $ swift post --read-acl "*:3de5f40b4e6d433792ac387896729ec8 " c-main-a

Get the credentials to access Object Store in “main”:

(owner) $ swift auth | awk -F = '/OS_STORAGE_URL/ {print $2}'
https://s3.waw3-1.cloudferro.com/swift/v1

Pass the link:

https://s3.waw3-1.cloudferro.com/swift/v1

to “user_1”

“user_1” should create an environmental variable “SURL”

(user_1) $ SURL=https://s3.waw3-1.cloudferro.com/swift/v1

Now the “user_1” has access to the “c-main-a” container in the “main” project:

(user_1) $ swift --os-storage-url="${SURL}" list c-main-a
test-main-a1.txt
test-main-a2.txt

But the user “user_1” has no access to other containers in the “main” project:

(user_1) $ swift --os-storage-url="${SURL}" list c-main-b
Container GET failed: https://s3.waw3-1.cloudferro.com/swift/v1/c-main-b?format=json 403 Forbidden [first 60
chars of response] b'{"Code":"AccessDenied","BucketName":"c-main-b","RequestId":"'
Failed Transaction ID: tx00000000000000397edda-0062b186ef-17379d9b-default

Similar procedure can be used to grant “write” permission to “user_1”:

(owner) $ swift post --write-acl "*:3de5f40b4e6d433792ac387896729ec8 " c-main-a

What To Do Next

These articles can also be of interest:

How to use Object Storage on CREODIAS.

Bucket sharing using s3 bucket policy on CREODIAS