[ English | Indonesia | Deutsch | 日本語 ]

Nutzerverwaltung

Das OpenStack Dashboard bietet eine grafische Oberfläche zur Verwaltung von Benutzern. Dieser Abschnitt beschreibt die Benutzerverwaltung mit dem Dashboard.

Sie können auch Projekte, Benutzer und Rollen über die Befehlszeilen-Clients verwalten.

Darüber hinaus schreiben viele Websites benutzerdefinierte Tools für lokale Anforderungen, um lokale Richtlinien durchzusetzen und Benutzern, die derzeit nicht mit verpackten Tools verfügbar sind, ein Niveau an Selbstbedienung zu bieten.

Neue Benutzer anlegen

Um einen Benutzer anzulegen, benötigen Sie die folgenden Informationen:

• Benutzername

• Beschreibung

• E-Mail-Adresse

• Passwort

• Primärprojekt

• Rolle

• Aktiviert

Benutzername und E-Mail-Adresse sind selbsterklärend, obwohl Ihre Website möglicherweise lokale Konventionen hat, die Sie beachten sollten. Das primäre Projekt ist einfach das erste Projekt, dem der Benutzer zugeordnet ist und das vor der Erstellung des Benutzers existieren muss. Die Rolle wird fast immer „Mitglied“ sein. OpenStack wird standardmäßig mit zwei definierten Rollen ausgeliefert:

Mitglied

Ein typischer Benutzer

admin

Ein administrativer Superuser, der über volle Berechtigungen für alle Projekte verfügt und mit großer Sorgfalt verwendet werden sollte

Es ist möglich, andere Rollen zu definieren, aber das ist ungewöhnlich.

Sobald Sie diese Informationen gesammelt haben, ist die Erstellung des Benutzers im Dashboard nur noch eine weitere Webform ähnlich dem, was wir zuvor gesehen haben und kann durch Anklicken des Links Users in der Navigationsleiste von Identity und dann durch Anklicken der Schaltfläche Create User oben rechts gefunden werden.

Die Änderung von Benutzern erfolgt ebenfalls über diese Seite Users. Wenn Sie eine große Anzahl von Benutzern haben, kann diese Seite sehr überfüllt sein. Das Suchfeld Filter oben auf der Seite kann verwendet werden, um die Benutzerliste einzuschränken. Ein Formular, das dem Dialog zur Benutzererstellung sehr ähnlich ist, kann aufgerufen werden, indem Sie Edit aus dem Dropdown-Menü Aktionen am Ende der Zeile für den Benutzer, den Sie ändern, auswählen.

Zuordnen von Benutzern zu Projekten

Viele Websites werden mit Benutzern betrieben, die nur einem Projekt zugeordnet sind. Dies ist eine konservativere und einfachere Wahl sowohl für die Administration als auch für die Benutzer. Administrativ, wenn ein Benutzer ein Problem mit einer Instanz oder Quota meldet, ist es offensichtlich, auf welches Projekt sich dies bezieht. Benutzer müssen sich keine Gedanken darüber machen, in welchem Projekt sie tätig sind, wenn sie nur in einem Projekt sind. Beachten Sie jedoch, dass jeder Benutzer standardmäßig die Ressourcen jedes anderen Benutzers innerhalb seines Projekts beeinflussen kann. Es ist auch möglich, Benutzer mehreren Projekten zuzuordnen, wenn dies für Ihr Unternehmen sinnvoll ist.

Das Zuordnen vorhandener Benutzer zu einem zusätzlichen Projekt oder das Entfernen aus einem älteren Projekt erfolgt über die Seite Projekte des Dashboards, indem Sie Mitglieder verwalten aus der Spalte Aktionen auswählen, wie im Screenshot unten gezeigt.

Aus dieser Sicht kannst du eine Reihe nützlicher Dinge tun, ebenso wie einige gefährliche.

Die erste Spalte dieses Formulars mit dem Namen Alle Benutzer enthält eine Liste aller Benutzer in Ihrer Cloud, die nicht bereits mit diesem Projekt verbunden sind. Die zweite Spalte zeigt alle Benutzer, die es sind. Diese Listen können recht lang sein, aber sie können eingeschränkt werden, indem Sie eine Teilzeichenfolge des gesuchten Benutzernamens in das Filterfeld oben in der Spalte eingeben.

Klicken Sie von hier aus auf das Symbol +, um Benutzer zum Projekt hinzuzufügen. Klicken Sie auf das -, um sie zu entfernen.

Die gefährliche Möglichkeit besteht in der Fähigkeit, die Rollen der Mitglieder zu wechseln. Dies ist die Dropdown-Liste unter dem Benutzernamen in der Liste Projektmitglieder. In praktisch allen Fällen sollte dieser Wert auf Member gesetzt werden. Dieses Beispiel zeigt gezielt einen administrativen Benutzer, bei dem dieser Wert admin` ist.

Warnung

Der Administrator ist global, nicht pro Projekt, so dass die Zuweisung der Rolle „Administrator“ in jedem Projekt dem Benutzer Administratorrechte in der gesamten Cloud gibt.

Typischerweise werden nur administrative Benutzer in einem einzigen Projekt erstellt, wobei das Admin-Projekt, das standardmäßig beim Cloud-Setup erstellt wird, als Konvention verwendet wird. Wenn Ihre administrativen Benutzer auch die Cloud zum Starten und Verwalten von Instanzen verwenden, wird dringend empfohlen, separate Benutzerkonten für den administrativen Zugriff und den normalen Betrieb zu verwenden und sich in verschiedenen Projekten zu befinden.

Customizing-Berechtigung

Die Standardeinstellungen von authorization erlauben es administrativen Benutzern, nur Ressourcen im Namen eines anderen Projekts zu erstellen. OpenStack verwaltet zwei Arten von Autorisierungsrichtlinien:

Operationsbasiert

Richtlinien legen Zugriffskriterien für bestimmte Vorgänge fest, möglicherweise mit fein abgestufter Kontrolle über bestimmte Attribute.

Ressourcenbasiert

Ob der Zugriff auf eine bestimmte Ressource gemäß den für die Ressource konfigurierten Berechtigungen gewährt werden kann oder nicht (derzeit nur für die Netzwerkressource verfügbar). Die tatsächlichen Autorisierungsrichtlinien, die in einem OpenStack-Dienst durchgesetzt werden, variieren von Bereitstellung zu Bereitstellung.

Die Richtlinien-Engine liest Einträge aus der Datei policy.json. Der tatsächliche Speicherort dieser Datei kann von Distribution zu Distribution variieren: Für nova befindet sie sich typischerweise in /etc/nova/policy.json. Sie können Einträge aktualisieren, während das System läuft, und Sie müssen die Dienste nicht neu starten. Derzeit besteht die einzige Möglichkeit, solche Richtlinien zu aktualisieren, darin, die Richtliniendatei zu bearbeiten.

Die Policy Engine des OpenStack-Dienstes stimmt direkt mit einer Policy überein. Eine Regel bezeichnet die Bewertung der Elemente solcher Politiken. Zum Beispiel in einem compute:create: "rule:admin_or_owner" Anweisung, die Richtlinie ist compute:create, und die Regel ist admin_or_owner.

Richtlinien werden von einer OpenStack-Richtlinien-Engine ausgelöst, wenn eine von ihnen mit einer OpenStack-API-Operation oder einem bestimmten Attribut übereinstimmt, das in einer bestimmten Operation verwendet wird. Beispielsweise testet die Engine die Richtlinie create:compute jedes Mal, wenn ein Benutzer eine POST /v2/{tenant_id}/servers Anfrage an den OpenStack Compute API-Server sendet. Richtlinien können auch mit einem bestimmten API extensions verbunden sein. Wenn ein Benutzer beispielsweise eine Erweiterung wie „compute_extension:rescue“ benötigt, lösen die durch die Provider-Erweiterungen definierten Attribute den Regeltest für diese Operation aus.

Eine Autorisierungsrichtlinie kann aus einer oder mehreren Regeln bestehen. Wenn mehr Regeln angegeben werden, ist die Evaluierungsrichtlinie erfolgreich, wenn eine der Regeln erfolgreich bewertet wird; wenn eine API-Operation mehreren Richtlinien entspricht, dann müssen alle Richtlinien erfolgreich bewertet werden. Außerdem sind die Autorisierungsregeln rekursiv. Sobald eine Regel abgeglichen ist, kann die Regel(n) in eine andere Regel aufgelöst werden, bis eine Terminalregel erreicht ist. Das sind die definierten Regeln:

Rollenbasierte Regeln

Bewerten Sie erfolgreich, ob der Benutzer, der die Anfrage abschickt, die angegebene Rolle hat. Beispielsweise ist "role:admin" erfolgreich, wenn der Benutzer, der die Anfrage absendet, ein Administrator ist.

Feldbasierte Regeln

Bewerten Sie erfolgreich, ob ein Feld der in der aktuellen Anforderung angegebenen Ressource mit einem bestimmten Wert übereinstimmt. Zum Beispiel ist "field:networks:shared=True"` erfolgreich, wenn das Attribut, das von der Netzwerkressource gemeinsam genutzt wird, auf true gesetzt ist.

Allgemeine Regeln

Vergleichen Sie ein Attribut in der Ressource mit einem Attribut, das aus den Sicherheitsdaten des Benutzers extrahiert wurde, und werten Sie erfolgreich aus, wenn der Vergleich erfolgreich ist. Beispielsweise ist "tenant_id:%(tenant_id)s" erfolgreich, wenn die Mandantenkennung in der Ressource gleich der Mandantenkennung des anfragenden Benutzers ist.

Hier sind Ausschnitte aus der Standarddatei nova policy.json:

{
   "context_is_admin":  "role:admin",
   "admin_or_owner":  "is_admin:True", "project_id:%(project_id)s",
   "default": "rule:admin_or_owner",
   "compute:create": "",
   "compute:create:attach_network": "",
   "compute:create:attach_volume": "",
   "compute:get_all": "",
   "admin_api": "is_admin:True",
   "compute_extension:accounts": "rule:admin_api",
   "compute_extension:admin_actions": "rule:admin_api",
   "compute_extension:admin_actions:pause": "rule:admin_or_owner",
   "compute_extension:admin_actions:unpause": "rule:admin_or_owner",
   "compute_extension:admin_actions:migrate": "rule:admin_api",
   "compute_extension:aggregates": "rule:admin_api",
   "compute_extension:certificates": "",
   "compute_extension:flavorextraspecs": "",
   "compute_extension:flavormanage": "rule:admin_api",
}

1. admin_or_owner zeigt eine Regel, die erfolgreich auswertet, wenn der aktuelle Benutzer ein Administrator oder der Eigentümer der in der Anfrage angegebenen Ressource ist (Mandantenkennung ist gleich).

2. default zeigt die Standardrichtlinie an, die immer dann ausgewertet wird, wenn eine API-Operation nicht mit einer der Richtlinien in policy.json übereinstimmt.

3. compute_extension:flavormanage zeigt eine Richtlinie, die die Möglichkeit der Manipulation von Varianten auf Administratoren beschränkt, die nur die Admin-API verwenden.

In einigen Fällen sollten einige Vorgänge auf Administratoren beschränkt sein. Daher sollten wir als weiteres Beispiel betrachten, wie diese Beispieldatei für Richtlinien in einem Szenario geändert werden könnte, in dem wir es den Benutzern ermöglichen, ihre eigenen Varianten zu erstellen:

{
  "compute_extension:flavormanage": ""
}

Benutzer, die andere Benutzer unterbrechen

Benutzer in Ihrer Cloud können andere Benutzer stören, manchmal absichtlich und böswillig, manchmal aus Versehen. Das Verständnis der Situation ermöglicht es Ihnen, eine bessere Entscheidung darüber zu treffen, wie Sie mit der Störung umgehen.

Beispielsweise hat eine Gruppe von Benutzern Instanzen, die eine große Menge an Rechenressourcen für sehr rechenintensive Aufgaben nutzen. Dies führt zu einer höheren Auslastung der Compute-Knoten und betrifft andere Benutzer. Überprüfen Sie in dieser Situation Ihre Benutzer-Anwendungsfälle. Sie werden feststellen, dass Szenarien mit hohem Rechenaufwand häufig auftreten und sollten dann eine angemessene Trennung in Ihrer Cloud planen, wie z.B. Host-Aggregation oder Regionen.

Ein weiteres Beispiel ist ein Benutzer, der eine sehr große Menge an Bandbreite verbraucht. Auch hier gilt es zu verstehen, was der Benutzer tut. Wenn sie natürlich eine hohe Bandbreite benötigt, müssen Sie möglicherweise ihre Übertragungsrate begrenzen, um andere Benutzer nicht zu beeinträchtigen oder sie in einen Bereich mit mehr Bandbreite zu verlegen. Auf der anderen Seite wurde vielleicht ihre Instanz gehackt und ist Teil eines Botnetzes, das DDOS-Angriffe startet. Die Lösung dieses Problems ist die gleiche wie wenn jeder andere Server in Ihrem Netzwerk gehackt wurde. Kontaktieren Sie den Benutzer und geben Sie ihm Zeit, zu antworten. Wenn sie nicht antwortet, beenden Sie die Instanz.

Ein letztes Beispiel ist, wenn ein Benutzer wiederholt auf Cloud-Ressourcen hämmert. Kontaktieren Sie den Benutzer und erfahren Sie, was er versucht zu tun. Vielleicht versteht er nicht, dass das, was er tut, unangebracht ist, oder es gibt ein Problem mit der Ressource, auf die er zuzugreifen versucht, das seine Anfragen in die Warteschlange stellt oder verzögert.