HowTo: Object Storage - Container/Bucket nutzen

OpenCloud Objektspeicher

TelemaxX bietet zwei Storage Services an, die ähnlich, aber nicht gleich und für unterschiedliche Anwendungsfälle gedacht sind:

TelemaxX S3 Object Storage

Eigenständige Cloud Service Plattform.

  • Use Case: Backup- & Archive-Storage mit Standard-Performance
  • Datenhaltung: Lokale Redundanz
  • Endpoint: s3.telemaxx.cloud
  • Dokumentation: TelemaxX S3 Object Storage
TelemaxX OpenCloud Object Storage

Integrierter S3 Service der OpenCloud Plattform.

  • Use Case: High-Performance Object Storage für Apps mit hohen Leistungsanforderungen
  • Datenhaltung: Redundant über 3 Rechenzentren gespiegelt
  • Endpoint: radosgw.opencloud.telemaxx.de
  • Dokumentation: diese Seite hier 😃

Jedes Projekt in der OpenCloud stellt auch einen Objektspeicher über Container bereit.
Diese ähneln AWS S3 Buckets und können ebenfalls über das S3 Protokoll angesprochen und verwaltet werden. Verwenden Sie Object-Storage Container, um beliebige Dateien zu speichern und sie bei Bedarf über eine öffentliche URL freizugeben.

Sie können Container und Daten über verschiedene Wege nutzen und verwalten:


Object Storage über das Dashboard managen

Sie können Daten entweder über das OpenCloud Dashboard oder über die CLI hinzufügen. Im Folgenden werden beide Wege beschrieben. Zuerst geht es um das Dashboard.

Container (Bucket) erstellen

Um einen Container zu erstellen, navigieren Sie zur Containers im linken Bereich Object Store. Dort sehen Sie eine einfache Oberfläche, die Ihre Container anzeigt und mit der Sie neue Container erstellen können.


Verwenden Sie die Schaltfläche + Container und geben Sie im Modalfenster den Namen Ihres Containers ein. Wählen Sie außerdem die Sichtbarkeit des Containers aus: public oder not public

Folder erstellen

Über die Schaltfläche + Folder können Ordnerstrukturen angelegt werden.

Daten hinzufügen

Klicken Sie in der Container-Übersicht auf den Container, den Sie verwalten möchten. Der Inhalt des Containers wird rechts angezeigt. Dort finden Sie auch die Upload-Schaltfläche.

Wählen Sie im Modalfenster die gewünschte Datei aus, geben Sie optional einen Dateinamen an und bestätigen Sie das Hochladen mit Upload File.

Public Access – Container-Daten öffentlich zugänglich machen

Hier können Sie außerdem die Sichtbarkeit des Containers ändern und den Freigabe-Link kopieren, sofern es sich um einen öffentlichen Container handeln soll.



Object Storage über die CLI managen

Voraussetzungen

Für die Nutzung werden folgende Werkzeuge benötigt:

  • OpenStack CLI
  • AWS CLI
  • jq – bessere Darstellung von JSON-Text (optional)
  • Zugriff auf ein OpenStack-Projekt bspw. mithilfe von Application Credentials

S3 Credentials erzeugen

S3-Zugangsdaten können über die OpenStack CLI wie folgt erstellt werden:

openstack ec2 credentials create

Die Ausgabe enthält unter anderem einen access und einen secret Wert.

+------------+----------------------------------------------------------------+
| Field      | Value                                                          |
+------------+----------------------------------------------------------------+
| access     | fd41da26fcbc4280ae3ae5ff6ac71346                               |
| links      | {'self': 'https://keystone.opencloud.telemaxx.de:5000/v3/...'} |
| project_id | 11111111111111111111111111111111                               |
| secret     | ********************************                               |
| trust_id   | None                                                           |
| user_id    | 22222222222222222222222222222222                               |
+------------+----------------------------------------------------------------+

Die AWS CLI kann nun über Umgebungsvariablen für den Zugriff auf S3 konfiguriert werden.

Beispiel:

export AWS_ACCESS_KEY_ID='fd41da26fcbc4280ae3ae5ff6ac71346'
export AWS_SECRET_ACCESS_KEY='********************************'
export AWS_ENDPOINT_URL='https://radosgw.opencloud.telemaxx.de'
export AWS_DEFAULT_REGION=default
export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
export AWS_RESPONSE_CHECKSUM_VALIDATION=when_required
ℹ️

Info: Die Variablen AWS_REQUEST_CHECKSUM_CALCULATION und AWS_RESPONSE_CHECKSUM_VALIDATION können notwendig sein, um Kompatibilitätsprobleme zwischen neueren AWS-CLI-Versionen und S3-kompatiblen Backends wie RadosGW zu vermeiden.

Bucket erstellen

Im folgenden Beispiel legen wir einen Bucket mit dem Namen awesome-bucket an.

Methode 1: über die OpenStack CLI

openstack container create awesome-bucket
ℹ️

Info: In OpenStack werden Buckets als Container bezeichnet.

Methode 2: über die AWS CLI

aws s3 mb s3://awesome-bucket
⚠️

Caveat: Eindeutige Bucket-Namen

Bucket-Namen beziehungsweise Container-Bezeichner sind global eindeutig. Das bedeutet, dass ein Bucket-Name nur einmal innerhalb der Object-Storage-Plattform vergeben werden kann. Auch wenn in Ihrem eigenen Projekt noch kein Bucket mit diesem Namen existiert, kann es sein, dass der gewünschte Name bereits durch ein anderes Projekt belegt ist. Wählen Sie in diesem Fall einen anderen, eindeutigen Bucket-Namen.

Objekte hochladen

Ein Objekt kann mit der AWS CLI in einen Bucket hochgeladen werden:

aws s3 cp image.png s3://awesome-bucket/

In diesem Beispiel wird die Datei image.png in den Bucket awesome-bucket hochgeladen.

Soll ein Objekt direkt öffentlich lesbar sein, kann es beim Upload mit der ACL public-read hochgeladen werden:

aws s3 cp image.png s3://awesome-bucket/ --acl public-read

Ein öffentliches Objekt kann anschließend über die folgende URL abgerufen werden:

https://radosgw.opencloud.telemaxx.de/awesome-bucket/image.png

Der Zugriff über diese URL funktioniert nur, wenn das Objekt oder der entsprechende Pfad öffentlich lesbar ist.

Alternativ kann ein temporärer, signierter Download-Link für private Objekte erstellt werden:

aws s3 presign s3://awesome-bucket/image.png --expires-in 3600

Der Parameter --expires-in gibt die Gültigkeit des Links in Sekunden an. In diesem Beispiel ist der Link eine Stunde gültig.

ACL eines bestehenden Objekts ändern

Die ACL eines bereits vorhandenen Objekts kann nachträglich gesetzt werden:

aws s3api put-object-acl --bucket awesome-bucket --key image.png --acl public-read

Damit wird das Objekt image.png im Bucket awesome-bucket öffentlich lesbar gemacht.

Übersicht gängiger ACLs

ACLScope
privateNur der Owner hat Vollzugriff. Kein öffentlicher Zugriff. Dies ist üblicherweise der Standard.
public-readDer Owner hat Vollzugriff. Jeder kann Objekte lesen.
authenticated-readJeder authentifizierte S3-Benutzer (auch außerhalb des eigenen Projekts) kann lesen.
⚠️ public-read-writeJeder (auch außerhalb des eigenen Projekts) kann lesen und schreiben.
Achtung: In der Regel vermeiden!

Zugriff auf einen Ordner bzw. Prefix erlauben

S3 kennt technisch keine echten Ordner. Stattdessen werden Pfade als sog. Prefixes innerhalb eines Buckets behandelt. Wenn alle Objekte unterhalb eines Prefixes öffentlich lesbar sein sollen, kann eine Bucket Policy verwendet werden.

ℹ️

ACL vs. Bucket Policy

ACLs eignen sich vor allem, wenn die Berechtigung für einzelne Buckets oder einzelne Objekte gesetzt werden soll, zum Beispiel um eine einzelne Datei mit public-read öffentlich lesbar zu machen.

Wenn jedoch mehrere Objekte nach einem gemeinsamen Prefix freigegeben werden sollen, ist eine Bucket Policy in der Regel besser geeignet. Ein typisches Beispiel ist ein Prefix wie images/*, bei dem alle darunterliegenden Objekte öffentlich lesbar sein sollen. Mit einer Policy kann die Berechtigung zentral auf das gesamte Prefix angewendet werden, ohne jedes einzelne Objekt nachträglich per ACL anfassen zu müssen.

Beispiel: Öffentlicher Lesezugriff auf alle Objekte unterhalb von images/.

Datei: allow-read.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadImagesPrefix",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::awesome-bucket/images/*"
      ]
    }
  ]
}

Die Policy wird anschließend wie folgt auf den Bucket angewendet:

aws s3api put-bucket-policy --bucket awesome-bucket --policy file://allow-read.json

Danach sind alle Objekte unterhalb des Prefixes images/ öffentlich lesbar, zum Beispiel:

https://radosgw.opencloud.telemaxx.de/awesome-bucket/images/image.png

Bucket Policy prüfen

Eine gesetzte Bucket Policy kann mit folgendem Befehl geprüft werden:

aws s3api get-bucket-policy --bucket awesome-bucket --output json | jq -r '.Policy'

Unter dem Key Policy finden wir den ursprünglichen Inhalt der JSON-Datei wieder:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadImagesPrefix",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::awesome-bucket/images/*"]
    }
  ]
}

S3 Policy Generator

Zum Erstellen von S3 Policies im geeigneten Format kann der AWS Policy Generator verwendet werden.

Dabei sollte darauf geachtet werden, dass der Amazon Resource Name (ARN) den passenden Bucket-Namen sowie das gewünschte Resource Pattern enthält, z.B.:

arn:aws:s3:::awesome-bucket/images/*

Typische Actions sind beispielsweise GetObject, PutObject und DeleteObject.

Nach einem Klick auf Generate Policy wird ein passendes JSON-Dokument erzeugt. Dieses kann anschließend, wie oben beschrieben, als Bucket Policy hinterlegt werden.