Objektspeicher / S3
Objektspeicher ist ein Datenspeicher, der seinen Ursprung in Cloud Umgebungen hat und zum Ablegen und Teilen von Daten verwendet werden kann. Ein Objekt besteht dabei aus einem eindeutigen Namen, den eigentlichen Daten, sowie zugehörigen Metadaten (wie z. B. Zugriffsberechtigungen und nutzerdefinierten Metadaten). Im Gegensatz zu Dateisystemen werden Objekte hierbei nicht in einer Hierarchie sondern in einem flachen Container (sog. Buckets) abgelegt. Der Zugriff erfolgt über auf HTTP-basierenden Protokollen/APIs wie S3 oder Swift.
Zugang
Über das Self-Service-Portal der TU Dresden kann von Mitarbeitenden und Studierenden ein Zugang zum Objektspeicherdienst beantragt bzw. eingerichtet werden. Dabei werden der Nutzername sowie die E-Mail-Adresse an den Dienst übermittelt und genutzt, um den Nutzeraccount zu identifizieren.
Nach Gewährung erhält man eine dem ZIH-Login zugeordnete Kennung bestehend aus Access Key (Zugangsschlüssel, vergleichbar mit einer pseudonymisierten Benutzerkennung) und Secret Key (geheimer Schlüssel, also ein geheimzuhaltendes Passwort), die im Self-Service-Portal eingesehen werden können. Bei Bedarf kann jederzeit ein neuer Secret Key generiert werden.
Es werden keine separaten Gruppenzugänge oder Zugänge, die nicht an ein ZIH-Login geknüpft sind, bereitgestellt. Für derartige Zwecke kann ein ZIH-Funktionslogin beantragt und der dazugehörige S3 Zugang genutzt werden.
Limitierungen
Der maximal einem Nutzer zur Verfügung gestellte Speicherplatz (Quota) ist begrenzt, initial auf 20 GB, kann jedoch über das Self-Service-Portal auf bis zu 200 GB erhöht werden. Darüberhinausgehendem Speicherplatzbedarf kann auf Antrag entsprochen werden.
Jeder Nutzer darf bis zu 50 Buckets anlegen, in denen er seine Objekte strukturiert ablegen kann. Die Anzahl der erlaubten Objekte ist derzeit nicht begrenzt, unterliegt aber u. U. praktischen Limitierungen.
Sicherheitshinweise
Achtung: Standardmäßig werden sämtliche Daten im Objektspeicher unverschlüsselt abgelegt. Auch das dahinterliegende Speichersystem verschlüsselt die Daten nicht, weswegen bei vertraulichen Daten unbedingt darauf zu achten ist, diese nur verschlüsselt im Objektspeicher abzulegen.
Falls die Klientensoftware selbst keine Verschlüsselung unterstützt, kann auf sog. server-side Encryption zurückgegriffen werden, die im S3 Protokoll spezifiert ist. Dabei werden die Daten beim Speichern mit einem vom Klienten zur Verfügung gestellten Schlüssel verschlüsselt. Der Transportweg ist verschlüsselt (HTTPS).
Client-Konfiguration (Beispiel)
Eine häufig verwendete Klientensoftware ist s3cmd, das über die Kommandozeile gesteuert werden kann. Das Werkzeug kann nach Installation interaktiv konfiguriert werden:
s3cmd --configure
- Access Key und Secret Key eingeben
- Die default Region beibehalten (Enter)
- S3 Endpoint: s3.zih.tu-dresden.de
- DNS-style bucket+hostname:port template for accessing a bucket: %(bucket)s.s3.zih.tu-dresden.de
Falls Verschlüsselung gewünscht ist:
- Encryption password: <Passwort>
- Path to GPG program [/usr/bin/gpg]: <Enter>
- Use HTTPS protocol: Yes
HTTP Proxy server name: <Enter>
Es wird eine Konfigurationsdatei ~/.s3cfg erzeugt, die auch direkt minimalistisch wie folgt befüllt werden könnte:
[default]
access_key = XXXXXXXXXXXXXXXXXXXX
secret_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
host_base = s3.zih.tu-dresden.de
host_bucket = %(bucket)s.s3.zih.tu-dresden.de
use_https = True
Zum Testen einen Bucket anlegen:
s3cmd mb s3://testbucket
s3cmd ls
Eine Datei als Objekt hochladen:
echo "Hello world" > mytestfile.txt
s3cmd put mytestfile.txt s3://testbucket
s3cmd info s3://testbucket/mytestfile.txt
Hinweis zur clientseitigen Verschlüsselung von s3cmd: Diese muss explizit durch Angabe des -e Parameter (bei put) aktiviert werden, oder alternativ encrypt = True in der Konfigurationsdatei angegeben werden, damit Objekte verschlüsselt abgelegt werden.
Namensraum
Jeder Nutzer bekommt seinen eigenen Namensraum für Buckets zugewiesen, sodass es bei der Vergabe von Bucketnamen zu keinen Kollisionen zwischen den Nutzern kommt. Dies hat jedoch Auswirkungen auf das Teilen von Objekten mit anderen Nutzern und dem öffentlichen Zurverfügungstellen von URLs. Hierbei muss stets der Namensraum mit angegeben werden, um Buckets eindeutig identifizieren zu können.
Öffentlichen Zugriff auf Objekte ermöglichen
s3cmd setacl --acl-public s3://testbucket/mytestfile.txt
s3cmd info s3://testbucket/mytestfile.txt
Zugriff: curl https://s3.zih.tu-dresden.de/zihloginname:testbucket/mytestfile.txt
Hinweis: Zugriff über Subdomain-basierte Bucketnames ist für unauthentisierte Zugriffe (also z. B. über den Webbrowser) in dem Fall nicht möglich, da sich die Buckets alle in einem bestimmten Namensraum befinden, dem der Besitzer zugeordnet ist. Dieser muss explizit mit angegeben werden. Doppelpunkte (:) sind kein valides Zeichen in Domainnamen, weswegen die Angabe hier nur über die Pfad-basierte Angabe möglich ist.
Öffentlichen Zugriff entziehen: s3cmd setacl --acl-private s3://testbucket/mytestfile.txt
Pre-signed URLs
Um Objekte für einen eingeschränkten Personenkreis zugreifbar zu machen, ohne dass Personen daraus selbst S3 Zugangsdaten haben müssen, können sog. pre-signed URLs verwendet werden. Dabei erzeugt man mit seinem eigenen Nutzer einen signierten Link, mit dessen Kenntnis der Zugriff auf ein Objekt ermöglicht wird. Üblicherweise werden derartige pre-signed URLs mit einer begrenzten Gültigkeitsdauer versehen.
s3cmd signurl s3://testbucket/mytestfile.txt $(date -d 'now + 1 year' +%s)
oder:
s3cmd signurl s3://testbucket/mytestfile.txt +3600
Da hierbei die Zuordnung zu einem Namensraum über den im URL enthaltenen Access Key geschieht, ist eine explizite Angabe des Namensraums nicht notwendig.
Datensicherheit
Eine redundante Speicherung aller Daten im Objektspeicher wird im dahinterliegenden Speichersystem erreicht (Ceph replicated pool), auch über zwei Standorte hinweg, um gegen Ausfall einzelner Teile gerüstet zu sein. Bei Ausfall des gesamten Speichersystems steht jedoch kein separates Backup zur Verfügung (-> kein Disaster Recovery).
Für die Nachvollziehbarkeit von Änderungen und um sich gegen versehentliche Änderungen abzusichern, werden sog. versionierte Buckets unterstützt. Dabei wird bei jeder Änderung an einem Objekt der alte Stand gespeichert und kann wiederhergestellt werden, ähnlich wie ein Snapshot in dateisystembasiertem Speicher. Die zusätzlichen Versionen zählen zum Nutzer-Quota, werden dabei aber inkrementell gespeichert, sodass nur der geänderte Anteil Speicherplatz belegt.
Zudem besteht die Möglichkeit, Objekte für eine gewisse Dauer vor nachträglicher Veränderung und Löschung zu schützen (sog. Object Locking), womit ein write-once-read-many (WORM) Speichermodell umgesetzt werden kann, das einen effektiven Schutz beispielsweise gegen Ransomware darstellt.