Benutzer, Rollen und Bereiche
Erfahren Sie, wie Mitglieder, Dienstkonten, Rollen, Rollenzuweisungen und Bereiche zusammenwirken, um den Zugriff in Ihrer Organisation zu steuern.
Identity & Access Management steuert, wer sich bei Ihrer Organisation anmelden kann und was diese Personen dort tun können. Was ein Mitglied oder ein Dienstkonto tun kann, ergibt sich aus seinen Rollenzuweisungen: einer Rolle, die dem Prinzipal in einem Bereich zugewiesen ist. Dieser Artikel erklärt jeden dieser Bestandteile.
Organisation und Bereiche
Ihre Organisation, auch Mandant genannt, enthält ein oder mehrere Abonnements, und jedes Abonnement enthält Projekte. Ressourcen wie Instanzen und Volumes befinden sich in Projekten. Siehe Mandanten, Abonnements, Projekte und Regionen.
Mitglieder, Dienstkonten und benutzerdefinierte Rollen gehören zur gesamten Organisation. Eine Rollenzuweisung gilt in einem von zwei Bereichen:
- Ein Abonnement. Die Zuweisung gilt für das Abonnement und für jedes Projekt darin.
- Ein Projekt. Die Zuweisung gilt nur für dieses Projekt.
Eine Rolle, die für das Abonnement Production zugewiesen ist, gilt z. B. in seinen Projekten web-platform und data-platform. Wird dieselbe Rolle für web-platform zugewiesen, gilt sie nur dort.
Prinzipale
Ein Prinzipal ist eine Identität, der Rollen zugewiesen werden können.
- Mitglieder sind Personen, die sich mit ihrer E-Mail-Adresse und ihrem Passwort bei der Konsole anmelden und, wenn die Zwei-Faktor-Authentifizierung aktiviert ist, mit einem Code aus einer Authenticator-App. Sie fügen Mitglieder per Einladung hinzu. Siehe Mitglieder einladen und verwalten.
- Dienstkonten sind Maschinenidentitäten für die Automatisierung. Diese melden sich nicht bei der Konsole an, sondern rufen die REST-API mit Schlüsseln auf, deren Secrets mit
sak_live_beginnen. Siehe Dienstkonten und API-Tokens.
Ein API-Token, dessen Geheimnis mit pc_live_ beginnt, ist kein eigener Prinzipal. Es handelt als das Mitglied, das es erstellt hat, beschränkt auf die Bereiche, die für das Token ausgewählt wurden.
Rollen und Berechtigungen
Eine Rolle ist eine Sammlung von Berechtigungen. Für jeden Berechtigungsbereich, z. B. Compute / Instances, Networking oder Identity & Access, gewährt die Rolle Keine, Lesen oder Verwalten. Mit Lesen kann der Inhaber der Rolle die Ressource anzeigen, und mit Verwalten kann er sie anzeigen und ändern.
- Integrierte Rollen. Besitzer, Mitwirkender, Leser und Abrechnungsoperator. Sie können sie nicht ändern.
- Benutzerdefinierte Rollen. Rollen, die Sie selbst definieren, von Grund auf neu oder durch Klonen einer anderen Rolle. Eine benutzerdefinierte Rolle kann z. B. Verwalten für Networking und Load Balancers gewähren und Lesen für alles andere.
Siehe Integrierte und benutzerdefinierte Rollen verwenden.
Rollenzuweisungen
Eine Rollenzuweisung gibt einem Prinzipal eine Rolle in einem Bereich, z. B. einem Mitglied die Rolle Mitwirkender für das Projekt web-platform. Ein Mitglied oder ein Dienstkonto kann mehrere Zuweisungen mit unterschiedlichen Rollen in unterschiedlichen Bereichen haben.
Bei jeder Anfrage prüft die Plattform die Rollenzuweisungen des Prinzipals, die für das Projekt gelten, und erlaubt die Anfrage nur, wenn sie den Zugriff gewähren, den die Anfrage benötigt. Wenn mehrere Zuweisungen gelten, addieren sie sich: Für jeden Berechtigungsbereich gilt die höchste Ebene, die eine von ihnen gewährt. Ein Mitglied, das z. B. die Rolle Leser für das Abonnement Production und die Rolle Mitwirkender für das Projekt web-platform hat, kann Ressourcen in web-platform ändern und die Ressourcen in den anderen Projekten von Production anzeigen.
Einige Abrechnungsressourcen gehören zum gesamten Abonnement: Rechnungen, Zahlungsmethoden, Guthaben und Verpflichtungen. Für diese zählen nur Zuweisungen auf Abonnementebene: Eine Rolle, die für ein Projekt zugewiesen ist, gewährt keinen Zugriff darauf, auch nicht die Rolle Besitzer. Der Cost Explorer, die Kostenübersicht und Budgets funktionieren auch mit einer Rolle, die für ein Projekt zugewiesen ist, und umfassen dann nur dieses Projekt.
Wer Zuweisungen ändern kann und was sie sonst noch festlegen:
- Gewähren. Um eine Rolle in einem Bereich zuzuweisen, benötigen Sie in diesem Bereich die Rolle Besitzer oder eine benutzerdefinierte Rolle mit der Zugriffsebene Verwalten für Identity & Access; für das Abonnement muss sie direkt für das Abonnement gewährt sein. Dort können Sie nur Rollen gewähren, die nicht höher eingestuft sind als Ihre eigene und deren Berechtigungen Sie selbst haben. Eine benutzerdefinierte Rolle kann nur in den Bereichen zugewiesen werden, die sie erlaubt.
- Organisationsweite Einstellungen. Um die Zwei-Faktor-Authentifizierung zu verlangen und den OpenStack-API-Zugriff ein- oder auszuschalten, ist die integrierte Rolle Besitzer auf Abonnementebene erforderlich. Eine benutzerdefinierte Rolle oder die Rolle Besitzer für ein einzelnes Projekt reicht nicht aus.
- Projekterstellung. Zum Erstellen von Projekten in einem Abonnement ist die Rolle Besitzer auf Abonnementebene oder eine separate Berechtigung zur Projekterstellung erforderlich. Siehe Mitglied das Erstellen von Projekten erlauben.
- OpenStack-Zugriff. Die Rolle eines Prinzipals in einem Projekt legt auch fest, welche OpenStack-Rollen seine Anwendungs-Credentials dort haben können. Siehe Was ist OpenStack API Access?
Authentifizierung
- Passwort. Mitglieder wählen ihr eigenes Passwort, wenn sie ihre Einladung annehmen.
- Zwei-Faktor-Authentifizierung. Mitglieder können ihre Anmeldung um einen Code aus einer Authenticator-App ergänzen, und ein Inhaber kann dies für Mitglieder verlangen. Siehe Zwei-Faktor-Authentifizierung erzwingen.
- Sitzungen. Jeder angemeldete Browser hat eine Sitzung, die Sie abmelden können. Siehe Sitzungen verwalten.
- Step-up-Bestätigung (erneute Zwei-Faktor-Bestätigung). Einige wenige sensible Aktionen fragen nach einem neuen Code aus Ihrer Authenticator-App, selbst in einer offenen Sitzung. Siehe Step-up-Bestätigung.