• »
  • OPENSTACK CLI »
  • Jak udostępnić prywatny kontener z obiektowej pamięci masowej innemu użytkownikowi w NSIS?

Jak udostępnić prywatny kontener z obiektowej pamięci masowej innemu użytkownikowi w NSIS?

Możesz tworzyć własne prywatne kontenery w Object Store swoich projektów i przyznawać dostęp do nich innym użytkownikom.

Jeśli chcesz ograniczyć dostęp wybranych użytkowników do określonych kontenerów, pozostali użytkownicy muszą być członkami innych projektów (zaleca się, aby na jeden projekt przypadał jeden użytkownik lub jedna grupa użytkowników).

Projekt może obejmować jedną lub więcej domen.

W przeciwnym razie, jeśli użytkownicy są członkami tego samego projektu, widzą wszystkie kontenery w tym projekcie i nie można ograniczyć dostępu do określonych kontenerów.

Wymagania wstępne

Nr 1 Hosting

Wymagane jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.

Nr 2 Klient OpenStack zainstalowany i połączony z chmurą

Poniższy artykuł pomoże ci zainstalować środowisko Python i klienta OpenStack o nazwie openstack, a także pomoże ci połączyć się z chmurą: Jak zainstalować OpenStackClient dla systemu Linux na NSIS).

Nr 3 Wiedza na temat pobierania plików RC i pracy z nimi

Aby umożliwić udostępnianie prywatnych kontenerów, konieczne będzie manipulowanie plikami RC z chmury. Szczegółowe informacje techniczne zawiera artykuł

/accountmanagement/How-to-activate-OpenStack-CLI-access-to-NSIS-Cloud-cloud

Nr 4. Używanie modułu OpenStack Swift

Moduł OpenStack Object Store, znany jako Swift, umożliwia przechowywanie i pobieranie danych za pomocą prostego interfejsu API. Został stworzony z myślą o skalowalności i jest zoptymalizowany pod kątem odporności, dostępności i współbieżności w całym zestawie danych. Swift jest idealny do przechowywania nieustrukturyzowanych danych, których wielkość może rosnąć bez ograniczeń.

Zobacz artykuł Jak uzyskać dostęp do object storage za pomocą OpenStack CLI na NSIS.

Konfigurowanie przykładu testowego

W poniższym przykładzie istnieją trzy projekty:

  1. „main”,

  2. „project_1”,

  3. „project_2”.

../_images/projects.png

… i trzech użytkowników:

../_images/users.png

Użytkownik „owner” ma w swoim projekcie „main” trzy kontenery…

  1. c-main-a,

  2. c-main-b,

  3. c-main-d.

../_images/owner_con.png

… oraz następujące pliki w kontenerach:

  • 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

W poniższym przykładzie użytkownik „owner” przyzna dostęp „tylko do odczytu” do kontenera „c-main-a” dla użytkownika „user_1”

Pobierz plik RC, aby udostępnić uprawnienia użytkownikom

Po pierwsze, użytkownik „właściciel” powinien zalogować się do swojej domeny, jeśli jeszcze tego nie zrobił:

../_images/owner_login_nsis_pl.png

Następnie powinni wybrać główny projekt:

../_images/owner_main.png

Następnie należy pobrać plik „OpenStack RC File” dla użytkownika „owner” i projektu „main”:

../_images/owner_rc.png

Informacja

Przyjmiemy najprostszy przypadek, w którym wszyscy trzej użytkownicy mają dostęp do chmury z uwierzytelnianiem jednoskładnikowym. Jeśli jest włączone uwierzytelnianie dwuskładnikowe, właściciel będzie musiał udostępnić sześciocyfrowy kod, który jest potrzebny jaki drugi skladnik uwierzytelniania.

Możesz wyświetlić podgląd zawartości tego pliku w terminalu Linux:

$ 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="WAW4-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!!!****

Udostępnianie pliku RC użytkownikom

Skopiuj plik main-openrc.sh do swojego katalogu CLI.

Użytkownik o nazwie „user_1” powinien wykonać tę samą procedurę:

  1. zalogować się do projektu „project_1”

  2. pobrać plik „OpenStack RC File” dla użytkownika „user_1” i projektu „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="WAW4-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!!!****

Użytkownik „user_2” powinien wykonać tę samą procedurę opisaną powyżej.

Użytkownik owner pozyskuje plik RC

Teraz każdy użytkownik powinien otworzyć terminal i pobrać plik openrc:

terminal użytkownika „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

Użytkownik user_1 pozyskuje plik RC

terminal użytkownika „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

Użytkownik user_2 pozyskuje plik RC

terminal użytkownika „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

Przesyłanie plików testowych

Użytkownik „owner” przygotowuje i przesyła pliki testowe:

(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

Sprawdź identyfikator użytkownika user_1:

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

Sprawdź identyfikator użytkownika user_2:

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

Możesz sprawdzić stan kontenera „c-main-a”.

Atrybuty „Read ACL” i „Write ACL” nie są jeszcze ustawione

(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

Przyznawanie dostępu

Przyznaj dostęp do kontenera „c-main-a” użytkownikowi user_1:

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

Uzyskaj poświadczenia dostępu do Object Store w projekcie „main”:

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

Przekaż link:

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

użytkownikowi „user_1”

Użytkownik „user_1” powinien utworzyć zmienną środowiskową „SURL”

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

Teraz użytkownik „user_1” ma dostęp do kontenera „c-main-a” w projekcie „main”:

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

Użytkownik „user_1” nie ma jednal dostępu do innych kontenerów w projekcie „main”:

(user_1) $ swift --os-storage-url="${SURL}" list c-main-b
Container GET failed: https://s3.waw4-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

Podobna procedura może zostać użyta do przyznania użytkownikowi „user_1” uprawnienia „write”:

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

Co można zrobić dalej?

Mogą być przydatne również te artykuły:

Jak korzystać z Object Storage w NSIS.

Udostępnianie bucketów przy użyciu polityki s3 bucket w NSIS