Traits
Infrastruktur für Cloudumgebungen beinhaltet fast immer Komponenten, die nicht direkt für Kunden nutzbar sind sondern die Infrastruktur erst für Kunden nutzbar machen. Je nach Cloudumgebung werden solche Komponenten als "Manager", "Controller", Controlplane" oder ähnlich bezeichnet. Es liegt im Interesse des Serviceproviders, möglichst wenige solcher Komponenten zu betreiben, weil deren Kosten auf die Kunden umgelegt werden müssen.
Deswegen sind Funktionen in Cloudumgebungen interessant, die es dem Serviceprovider erlauben, Kunden quasi exklusiv Computeknoten zur Verfügung zu stellen (die der Kunde natürlich dementsprechend bezahlt), ohne dass dafür erneut Verwaltungsinfrastruktur aufgebaut werden muß. Die Verwaltungs- und die Netzwerkinfrastruktur werden gemeinsam mit anderen Kunden genutzt - bei der Computeinfrastruktur gibt es einen Pool, der von allen Kunden genutzt werden kann sowie dedizierte "Inseln", die nur bestimmten Kunden zur Verfügung stehen.
Im anderen Kontext könnten diese "Inseln" natürlich auch aus Hardware bestehen, die bestimmte Eigenschaften hat. Z. B. Systeme mit SSDs, NVMEs, HDDs oder auch GPUs bzw. FPGAs. Oder bestimmte Computeknoten könnten nur für bestimmte Applikationen benutzt werden.
In Triton existiert dafür das Konzept der Traits (Merkmale). Mit Traits können auf der einen Seite Computeknoten und auf der anderen Seite Triton Packages versehen werden. Beispiele für Traits aus der Dokumentation sind:
{
"ssd": true,
“hw”: ["richmond-a”, "richmond-b”, "mantis-shrimp"]
}
Stimmt der Trait aus dem Package mit einem der Traits auf dem Computeknoten überein, kann eine Instanz auf dem Computeknoten gestartet werden. Stimmt keiner der Traits überein, kann Triton die Instanz auf dem Computeknoten nicht starten.
// Package:
{
"ssd": true,
“hw”: ["richmond-a”, "richmond-b”, "mantis-shrimp"],
“app”: “hello world”
}
// Compute Node:
{ "ssd": true,
"hw": "richmond-a",
"app": "hello world"
}
Die Traits können über das Admin-Portal jeweils für Packages
und Server
vergeben werden. Packages können von Usern/Kunden nicht verändert werden. Bei der Erstellung oder Veränderung von Packages kann diesen ein Besitzer/Owner zugewiesen werden. Packages ohne Owner können von allen Tritonbenutzern verwendet werden - Packages mit Owner stehen nur diesem für das Provisionieren von Instanzen zur Verfügung. Triton erzeugt für Packages automatisch eine eindeutige Billing-ID, die für die Abrechnung verwendet werden kann.
Durch die Vergabe von Traits (z. B. für einzelne Kunden) und das Erzeugen von kundenspezifischen Packages ist es also möglich, Kunden dedizierte Computeknoten innerhalb einer bestehenden Triton Cloud zur Verfügung zu stellen, ohne erneut Verwaltungsinfrastruktur dafür aufzubauen. Dabei ist es dem Kunden durch die richtige Verwendung der Packages überlassen, ob er auf "seinen" Computeknoten provisioniert oder Computeknoten aus der Shared-Umgebung verwendet. Abgerechnet wird dann an Hand der Billing-ID entweder der Preis für die "Shared Cloud" oder für die "Private Cloud".
Provisionierungslimits in der Cloudapi
Für Tritons Cloudapi (Github) gibt es ein Plugin, über welches sich Provisionierungslimits umsetzen lassen. Das Plugin ist auch ein schönes Beispiel für Dokumentation innerhalb des Codes.
Das Plugin hilft z. B. dabei, Testaccounts mit eingeschränkten Ressourcen zu provisionieren und diese - nachdem der Support die Kreditwürdigkeit geprüft hat -deutlich zu erweitern. Dabei werden Standardlimits in der SAPI gespeichert. Limits, die von diesen Standards abweichen, werden im ufds (LDAP) gespeichert. Dabei kann man über das "tenant"-Attribut Gruppenlimits (z. B. für bestimmte Tenants) vergeben. Es ist aber auch möglich über die adminui, für jeden User individuelle Limits zu vergeben:
Role Based Access Control (RBAC)
RBAC kommt auf verschiedenen Ebenen zum Einsatz. Einerseits exitiert innerhalb von Triton Accounts ein System, wie sogenannte SubUser mit verschiedenen Rollen (und damit Rechten) ausgestattet werden können und andererseits wird RBAC auf Betriebssystemebene verwendet um verschiedene administrative Rechte zu vergeben und durchzusetzen.
RBAC in Triton Accounts
Innerhalb eines Triton Accounts können Kunden mit Hilfe des sdc-user Kommandos verwaltet werden:
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# sdc-user help create
Creates a new User for your account.
Usage:
sdc-user create [OPTIONS]
Options:
--login=ARG User login name (required).
-h, -?, --help Show this help.
--name=ARG User given name.
--surname=ARG User surname.
--address=ARG User address.
--city=ARG User city.
--company=ARG User company.
--country=ARG User country.
--email=ARG User email adress (required).
--phone=ARG User phone number.
--postal-code=ARG User postal code.
--state=ARG User state.
--password=ARG User password (required).
Da wir bisher nur das node-triton CLI verwendet haben, muß möglicherweise das node-smartdc CLI noch nachinstalliert werden. Wie man sich vorstellen kann, stammen die Kommandos, die node-smartdc zur Verfügung stellt
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# sdc-
sdc-addmachinetags sdc-deletemachine sdc-getaccount sdc-getpackage sdc-listmachinesnapshots sdc-role
sdc-chmod sdc-deletemachinemetadata sdc-getfirewallrule sdc-info sdc-listmachinetags sdc-startmachine
sdc-createfirewallrule sdc-deletemachinesnapshot sdc-getimage sdc-listdatacenters sdc-listnetworks sdc-startmachinefromsnapshot
sdc-createimagefrommachine sdc-deletemachinetag sdc-getkey sdc-listfirewallrulemachines sdc-listpackages sdc-stopmachine
sdc-createkey sdc-disablefirewallrule sdc-getmachine sdc-listfirewallrules sdc-nics sdc-updateaccount
sdc-createmachine sdc-disablemachinefirewall sdc-getmachineaudit sdc-listimages sdc-policy sdc-updatefirewallrule
sdc-createmachinesnapshot sdc-enablefirewallrule sdc-getmachinemetadata sdc-listkeys sdc-rebootmachine sdc-updateimage
sdc-deletefirewallrule sdc-enablemachinefirewall sdc-getmachinesnapshot sdc-listmachinefirewallrules sdc-renamemachine sdc-updatemachinemetadata
sdc-deleteimage sdc-exportimage sdc-getmachinetag sdc-listmachinemetadata sdc-replacemachinetags sdc-user
sdc-deletekey sdc-fabric sdc-getnetwork sdc-listmachines
sdc-resizemachine
aus älteren Versionen von Triton als das Produkt noch unter dem Namen "SmartDatacenter" bekannt war. Teilweise sind die Funktionen schon in das triton-CLI übernommen worden, teilweise (wie im Fall von sdc-user) aber auch nicht.
Kunden können innerhalb ihres Accounts also beliebig selbst User verwalten. Dazu gehört auch, ssh-Keys für diese zu hinterlegen, etc. Das Triton Portal bietet natürlich auch eine Weboberfläche dafür. Aber dieses steht uns nicht zur Verfügung. Wie man in der sdc-Befehlsübersicht schon sieht, gibt es die Kommandos sdc-policy und sdc-role, um Rollen zu definieren, diesen User zuzuweisen und diesen damit bestimmte Rechte zuzugestehen oder zu entziehen.
Zu diesem Zweck hat Joyent extra ein Access Control System namens Aperture entworfen, welches eine leicht zu benutzende Sprache beinhaltet, in welcher man Policies formulieren kann.
Damit ist es für Kunden relativ einfach möglich, Rollen für Supportmitarbeiter (die z. B. nur Leserechte haben) oder für Operatoren (die z. B. Instanzen starten/stoppen und löschen können) zu definieren und diesen dann User zuzuweisen. Beispiele für den Umgang mit den Tools sind in der rechten Spalte verlinkt.
RBAC in SmartOS
Die Zugriffsrechte auf Betriebssystemebene sind komplett von denen der Cloudumgebung getrennt. In SmartOS stehen für die Definition von Rollen die Mechanismen des Betriebsystems zur Verfügung.
SmartOS hat die Mechanismen von Solaris "geerbt", welches bereits ein komplettes RBAC-System enthält. Die entsprechenden Konfigurationen finden sich unterhalb von /etc/security in den Verzeichnissen/Dateien auth_attr, prof_attr und exec_attr.
Um z. B. unprivilegierten Usern des Systems die Verwaltung von ZFS-Datasets zu erlauben, würde man ihnen die Rolle "ZFS File System Management" zuweisen:
usermod -P "ZFS File System Management" <username>
Soll der User ZFS-Pools verwalten dürfen, bekommt er die Rolle "ZFS Storage Management"
usermod -P "ZFS Storage Management" <username>
SmartOs bringt derzeit 165 Sicherheitsattribute mit, die man Usern bzw. Rollen zuweisen kann. Das System erlaubt es z. B. auch "root" als Rolle zu definieren und auf diese Weise selbst den Superuser-Account in RBAC einzubinden.
Zusätzlich zu den Sicherheitsattributen gibt es noch ein feingranulares Rechtemodell für Prozesse, mit dem es möglich ist, einzelnen Programmen privilegierte Rechte bei der Ausführung einzuräumen, sodass auch "normale" Benutzer diese ausführen können. Diese Prozessprivilegien und das RBAC-System bieten gute Möglichkeiten, eine abgestufte Administration der Umgebung durchzusetzen. Das Video in der rechten Spalte zeigt u. a. ab Minute 34, wie diese Abstufung bei Joyent mit einem zentralen LDAP-System für alle Logins umgesetzt wurde (das Video ist übrigens von 2012).
Die Ausführung jedes Kommandos wird auf SmartOS in einem Audit-Log mitgeschrieben. Das macht durchgeführte Arbeiten transparent. Die Logs werden unter /var/audit geschrieben und sind mit dem Kommando praudit zu lesen.
Mit Hilfe von bart, dem basic audit reporting tool, stellt SmartOS ein Werkzeug zur Verfügung um den Inhalt von Filesystemen - oder Teilbäumen davon - zu vergleichen. So können z. B. zyklisch bestimmte Bereiche miteinander verglichen und (ungewollte) Änderungen aufgespürt werden.
Links
Using access control with CloudAPI
Getting started with access control: CLI
Getting started with access control: portal
SmartOS Operations