In diesem Teil möchte ich beschreiben, auf welche Art und Weise in der Praxis die Nutzung des Object Storage Service (OSS) funktionieren könnte. Im letzten Teil wurde nach der allgemeinen Einführung ein Bucket angelegt, woraufhin bereits Dateien in den OSS hochgeladen werden konnten – entweder per web-basierter Admin-UI oder auch per Desktop-Anwendung.
Das funktioniert zwar soweit gut, aber wenn ich davon ausgehe, beispielsweise Hugo als Generator für statische Webseiten zu nutzen, ist eine Consolen-Anwendung (Command Line Interface, CLI) letztlich praktischer. Hugo wird bereits auf der Console bedient, und wenn im Anschluss an die erfolgreiche Generierung der Website, d.h. der Verzeichnisse und Dateien, aus denen die statische Site besteht, der Schritt des Hochladens bzw. der Veröffentlichung ebenfalls mit der Console erledigt werden könnte, würde das einen gewissen Medienbruch (Web-UI bzw. Desktop vs. CLI) ersparen. Darüber hinaus ließe sich die CLI-Anwendung wesentlich besser in einen Continuous-Deployment-Workflow einbinden.
Viele Wege führen nach RAM
Bei all dem sollte jedoch das Thema Sicherheit nicht außer Acht gelassen werden. Natürlich könnte man alle Aktionen in der gesamten Alibaba Cloud mit einem User und den dazu gehörigen Credentials, d.h. Access Key ID und Access Key Secret durchführen. Dieser User wäre unter einem Linux-System somit der User root, und der darf bekanntlich alles. Analog zu Linux bzw. Unix sollte man jedoch nicht als root arbeiten, zu groß sind die Gefahren – einerseits durch den Benutzer selber, beispielsweise vielleicht doch versehentlich einmal mehr zu löschen als man wollte, oder eben für den Fall, dass ein Angreifer mit einem root-Account wirklich in jeden Bereich des Systems hinein gelangt, anstatt dass der kompromittierte Bereich sich auf einen einzelnen User beschränkt. Genau wie auf Betriebssysteme-Ebene gilt dies auch für die Arbeit mit den verschiedenen Diensten in der Alibaba Cloud bzw. allgemein für jeden Cloud-Dienstleister. Anwendungsszenarien für den Sinn und Zweck, unterschiedliche User einzurichten, gibt es zuhauf, man denke nur daran, einen persönlichen Account zu nutzen, dessen Inhaber aus dem Unternehmen ausscheidet. Die Verwendung von generischen Usern ist ebenfalls nicht sinnvoll, da sich dann nicht mehr nachvollziehen ließe, welcher User eine Aktion tatsächlich ausgeführt hat. Ein anderes Beispiel – es seien Zugangsdaten kompromittiert worden. Ein Angreifer würde im Falle des globalen Users den Zugriff auf alle Bereiche erhalten, andernfalls wäre der Zugriff vielleicht nur auf einzelne Services möglich. Und so weiter, insgesamt sollte die Nutzung von unterschiedlichen Usern einher gehend mit unterschiedlichen Rechten auf einzelne Bereiche eine logische Konsequenz sein.
Damit einher geht jedoch eine gewisse Komplexität, denn bei all diesen Zugangssystemen muss erst einmal die Frage geklärt werden: Wer darf was? Wobei in der Praxis noch ein, zwei Ebenen dazu kommen, und zwar lassen sich User meist Gruppen (Groups) zuweisen, wobei die Rechte dann jeweils den Gruppen zugeordnet werden. Eine weitere Ebene stellt die Rolle (Role) dar, die als eine Art Abstraktion zu den einzelnen Rechten dient. Mit Rechten wiederum ist der lesende bzw. schreibende Zugriff auf Ressourcen von Cloud-Diensten gemeint. Willkommen im Resource Access Management (RAM) Dschungel!
Tatsächlich bereitet mir dieser Teil der Serie die meisten Schwierigkeiten. Zum einen hat Alibaba Cloud die Admin-UI kurz nachdem ich die Role, Policy und den User einmal angelegt und mir sozusagen eine kleine Schneise in den Dschungel geschlagen hatte, drastisch geändert. Zwar gibt es noch immer User, Policies und Roles, aber dennoch habe ich den Eindruck, dass das System ein wenig verschlankt und besser benutzbar gestaltet wurde. Das trifft auch auf die Dokumentation zu, die mit wenigen Schritten einen RAM User generiert und die entsprechende Rechte zuweist. Immerhin sind die von mir generierten User, Role und Policy übernommen worden und behalten ihre Gültigkeit. Dennoch sind die Screenshots, die ich während meiner ersten Experimente mit RAM angefertigt habe, inzwischen als veraltet anzusehen. Zum anderen muss ich gestehen, dass die Schritte in der RAM-UI wirklich mehr experimentellen Charakter hatten. Das Ziel war klar – ein User, der ein bestimmtes OSS-Bucket beschreiben darf, um die Dateien hochladen zu können. Lesender Zugriff müsste hingegen von überall her erlaubt sein, schließlich soll die Web-Site, bestehend aus statischen Dateien, letztlich veröffentlicht werden. Insofern habe ich zunächst ein Bucket namens “geschkenet-site” in der OSS Admin-UI angelegt und mich daraufhin in die Untiefen des RAM gewagt.
Die folgende Darstellung beschreibt somit nur einen Weg, eine Möglichkeit, die letztlich sogar zum Erfolg geführt hat. Es gibt aber mit einiger Sicherheit weitere, evtl. bessere, kürzere, sicherere Wege, das Ziel zu erreichen. Denn wenn ich ehrlich bin, gehört dieser Teil der Alibaba Cloud, d.h. das Resource Access Management (RAM) nicht zu den Tools, denen man unbedingt eine hohe Sympathie angedeihen lässt. Mir geht es zumindest so, aber um das Ziel zu erreichen, ist eine gewisse Beschäftigung mit Zugriffsbeschränkungen, Rechten bzw. allgemein Sicherheit ebenfalls vonnöten. Nicht zuletzt stellt sich die Frage der Reihenfolge der einzelnen Schritte. Wie erwähnt, ist eine gewisse Komplexität vorhanden, weshalb die nachfolgend dargestellte Reihenfolge der Bearbeitung nicht derjenigen entsprechen muss, die ich seinerzeit ausgeführt habe. Um die aktuelle Version von RAM zu berücksichtigen, werde ich an geeigneter Stelle Screenshots des jeweiligen Status quo einsetzen, anhand der zumindest das Ergebnis der einzelnen Schritte geprüft werden kann.
Die ersten Schritte mit RAM in der Praxis – und einigen Tests
Wie bei allen Services der Alibaba Cloud, muss man sich auch für RAM explizit anmelden. Zwar ist die Benutzung verständlicherweise mit keinerlei Kosten verbunden, aber eine Anmeldung ist dennoch notwendig.
Und wieder heißt es, die Bedingungen zu akzeptieren – welche Wahl sollte man auch haben?
Nach erfolgter Anmeldung befindet man sich im Dashboard, das seinerzeit wie folgt ausgesehen hat.
In der aktuellen Admin-UI hat sich einiges verändert, die aktuelle Fassung sieht ein wenig anders aus.
Wie zu erkennen ist, werden Hinweise zur Verbesserung der Sicherheit gegeben. Die einzelnen Bereiche lassen sich aufklappen, darin befinden sich jeweils weitere Details.
Ein User muss her
Wie bereits erwähnt, sollte ein User angelegt werden, dem speziell für ein OSS-Bucket Zugriffsrechte gegeben werden. Der Dialog zum Anlegen eines Users zeigt keine Überraschungen, ich habe hier einen generischen Namen genutzt, der den Zweck verdeutlichen soll.
Nach dem Anlegen des Users wird dessen Access Key generiert, falls diese Option gewählt worden war.
Der neue User findet sich auch sogleich in der “User Management”-Liste im RAM wieder.
Das gilt ebenso für die neue Ansicht des User Managements, wobei der User hier eine ID in Form einer Subdomain erhalten hat (hier ausgegraut).
Ebenfalls können die Details des Users angezeigt werden, es folgt die alte Ansicht, die der neuen UI jedoch noch sehr ähnlich sieht, weshalb ich auf einen neuen Screenshot verzichtet habe.
Es folgt die Role
Als nächstes habe ich eine Role, zu deutsch Rolle, erstellt. Eine Warnung vorweg – in der aktuellen Fassung nennt Alibaba Cloud die Role nur noch “RAM Role” und misst dem Konzept insgesamt weniger Bedeutung zu, so zumindest mein Eindruck. Die UI und insgesamt die Bezeichnungen haben sich ebenfalls verändert, statt der Wahl zwischen “User Role” und “Service Role” wird der Typ der Role nun zwischen “Alibaba Cloud Account” und “Alibaba Cloud Service” festgelegt. Daher sind die folgenden Schritte eher für eine Reise in die Vergangenheit interessant, ich habe sie dennoch hier dargestellt, da ansonsten dieser Baustein komplett fehlen würde.
Zunächst führt der Dialog somit zur Erstellung der Role, hier eine “User Role”.
Danach wird für die “User Role” – und nur dafür, denn die Auswahl des Typs für eine “Service Role” ist eine völlig andere, ein “Trusted Account” festgelegt, ich habe hier die ID des eigenen Accounts eingetragen.
Danach müssen Name und optional die Beschreibung festgelegt werden, ich habe dabei den Role-Namen so angelegt, dass auf den ersten Blick klar wird, was damit bezweckt werden soll.
Das war es auch schon! Die neu angelegte Role wird einerseits bestätigt, andererseits findet sie sich bereits in der Liste der Roles wieder.
Zugriffsregelung per Custom Policy
Zum Schluss folgt die Custom Policy – hier werden die einzelnen Rechte im Detail festgelegt. Neben der Custom Policy gibt es die von Alibaba Cloud erstellten System Policies, die zwar vom User eingesetzt, aber nicht modifiziert werden können. Die Liste der System Policies ist lang, meist handelt es sich um Richtlinien für den lesenden und vollständigen Zugriff auf einzelne Cloud-Dienste.
Der folgende Screenshot zeigt die Custom Policy für den vollständigen, d.h. Lese- und Schreibzugriff auf das OSS-Bucket namens “geschkenet-site”. Ich gebe zu, mich hier schamlos an Beispielen aus der Alibaba Cloud Dokumentation bedient zu haben, es dürfte sich um die Seite “Authorization for OSS instances” gehandelt haben.
Dennoch ging der erste Version auch prompt daneben – zwar wurde die Policy erzeugt, führte aber nicht zum gewünschten Erfolg.
Hier die bereits erwähnte Erfolgsmeldung.
Beim zweiten Versuch und mit korrekter Schachtelung konnte die Policy dann auch erfolgreich eingesetzt werden – der folgende Screenshot zeigt die aktuelle Fassung innerhalb der aktuellen Admin-UI. Die Policies werden übrigens automatisch versioniert, so dass man jederzeit auf eine ältere zurück greifen kann (Reiter “Versions”).
Die Policies, d.h. sowohl System Policies als auch Custom Policies lassen sich dann wiederum Usern, Groups oder Roles zuordnen.
Auch dieser Dialog hat sich in der aktuellen Version stark geändert.
Das soll nun auch zum Thema Zugriffsrechte, Regeln und so weiter genügen. Denn nachdem der eingangs neu angelegte User hoffentlich die geeigneten Rechte erhalten hat, um auf das Bucket lesend wie schreibend zugreifen zu können, soll ein Tool auf der Kommandozeile dafür genutzt werden.
Zugriff via CLI-Tool ossutil
Alibaba Cloud bietet dafür inzwischen mehrere Tools an, ich habe mich seinerzeit rein willkürlich und ohne alle Programme zu testen für ein Tool namens ossutil entschieden. Ossutil wird für Windows und Linux jeweils in einer 32- und 64-Bit-Fassung angeboten, für den Mac unter Mac OS gibt es nur eine 64-Bit-Version. Alibaba weist zwar nicht direkt darauf hin, aber auch das in Go geschriebene ossutil ist Open Source und steht auf der entsprechenden GitHub-Seite zur Verfügung. Ich habe mir die Linux-Fassung herunter geladen, es handelt sich um ein einziges Binary, das natürlich Vorbehalte wecken mag, aber in diesem Fall besteht immer noch die Möglichkeit, sich den Quellcode zu clonen und es einfach selbst zu erzeugen.
Ansonsten sind die Installationsschritte wie bei Go-Binaries sehr einfach gehalten.
geschke@gohlis:~$ wget http://gosspublic.alicdn.com/ossutil/1.4.2/ossutil64?spm=a2c63.p38356.a3.4.4a3249daK0dETV geschke@gohlis:~$ mv ossutil64\?spm\=a2c63.p38356.a3.4.4a3249daK0dETV ossutil geschke@gohlis:~$ chmod a+x ossutil geschke@gohlis:~$ sudo mv ossutil /usr/local/bin/
Die ID im Query-String ist in der Download-URL der o.g. Seite enthalten. Es funktioniert zwar auch ohne, aber ich empfehle, die jeweils aktuelle Version des Tools mittels der Download-Links zu nutzen. Ich habe mir ossutil in einen Pfad kopiert, der standardmäßig durchsucht wird, so dass das Tool ohne weitere Vorkehrungen aufgerufen werden kann.
Die Konfiguration kann interaktiv erfolgen, letztlich sind nur Endpoint, Access Key ID und Access Key Secret einzugeben. Der ebenfalls abgefragte “stsToken” ist hingegen optional, also habe ich ihn leer gelassen, da ich mich zu diesem Zeitpunkt nicht mit einem weiteren Zugriffs-und-Rechte-Konzept beschäftigen wollte.
geschke@gohlis:~$ ossutil config The command creates a configuration file and stores credentials. Please enter the config file path(default /home/geschke/.ossutilconfig, carriage return will use the default path. If you specified this option to other path, you should specify --config-file option to the path when you use other commands): No config file entered, will use the default config file /home/geschke/.ossutilconfig For the following settings, carriage return means skip the configuration. Please try "help config" to see the meaning of the settings Please enter language(CH/EN, default is:EN, the configuration will go into effect after the command successfully executed): Please enter endpoint:oss-eu-central-1.aliyuncs.com Please enter accessKeyID:<hier access-key-ID eingeben> Please enter accessKeySecret:<hier access-key Secret eingeben> Please enter stsToken:
Dieser Config-Schritt legt letztlich eine Datei .ossutilconfig im Home-Verzeichnis des User an, in der die eingegebenen Daten gespeichert werden.
Mit dem Parameter “help” kann eine Liste der zur Verfügung stehenden Kommandos angezeigt werden.
geschke@gohlis:~$ ossutil help
Usage: ossutil [command] [args...] [options...]
Please use 'ossutil help command' to show help of command
Commands:
mb cloud_url [options]
Make Bucket
ls [cloud_url] [options]
List Buckets or Objects
rm cloud_url [options]
Remove Bucket or Objects
stat cloud_url [options]
Display meta information of bucket or objects
[...]
Angesichts der zuvor vergebenen Zugriffsrechte wird dem speziell auf das Bucket “geschkenet-site” eingerichteten User jedoch eine Liste der Buckets verweigert:
geschke@gohlis:~$ ossutil ls Error: oss: service returned error: StatusCode=403, ErrorCode=AccessDenied, ErrorMessage=You are forbidden to list buckets., RequestId=5BF4496...
Jedoch lässt sich der Status anzeigen, dies dient somit als erste Kontrolle, ob die Konfiguration erfolgreich war:
geschke@gohlis:~$ ossutil stat oss://geschkenet-site Name : geschkenet-site Location : oss-eu-central-1 CreationDate : 2018-11-20 18:18:28 +0100 CET ExtranetEndpoint : oss-eu-central-1.aliyuncs.com IntranetEndpoint : oss-eu-central-1-internal.aliyuncs.com ACL : public-read Owner : <owner id> StorageClass : Standard 0.311366(s) elapsed
So weit, so gut. Tatsächlich lassen sich auch die Inhalte des Buckets anzeigen, dazu muss analog zum vorherigen Kommando der Bucket-Name angegeben werden:
geschke@gohlis:~$ ossutil ls oss://geschkenet-site LastModifiedTime Size(B) StorageClass ETAG ObjectName 2018-11-20 19:46:56 +0100 CET 7073 Standard 081C9170ABE4514708CC324CC592CC51 oss://geschkenet-site/categories.html [...]
In diesem Beispiel hatte ich bereits Inhalte in das Bucket kopiert, so dass eine Liste der Dateien und Verzeichnisse ausgegeben wird.
Um Dateien in das Bucket hochzuladen, kann einfach das Copy-Kommando (ossutil cp) verwendet werden. Nehmen wir also an, dass sich alle zu kopierenden Dateien und Verzeichnisse im Verzeichnis namens “public” befinden, würde folgendes funktionieren:
geschke@gohlis:~/hugo/geschkenet$ ossutil cp public oss://geschkenet-site/ -r Succeed: Total num: 129, size: 9,505,774. OK num: 129(upload 100 files, 29 directories). 11.775806(s) elapsed
Dass das Kopieren bzw. Hochladen funktioniert hat, lässt sich leicht mit “ossutil ls oss://geschkenet-site” überprüfen. Mit “ossutil help cp” lassen sich übrigens Hinweise zu den Parametern des Copy-Kommandos anzeigen, denn zur Aktualisierung von Dateien genügt es, die jeweils neuen Dateien hochzuladen, dank des Parameters “-u” auch kein Problem:
geschke@gohlis:~/hugo/geschkenet$ ossutil cp public oss://geschkenet-site/ -r -u Succeed: Total num: 129, size: 9,505,539. OK num: 129(upload 26 files, skip 103 files), Skip size: 9,327,438. 1.979917(s) elapsed
So viel erstmal für heute, im nächsten Teil widme ich mich der endgültigen Konfiguration von OSS und dessen Nutzung zum Hosting von statischen Dateien, wobei ich ebenfalls darauf eingehen werde, welche möglichen Nachteile es dabei gibt.
