Verwenden von CA AppLogic® › Grid-Administrationshandbuch › Rollenbasierte Zugriffskontrolle › Objekte migrieren
Objekte migrieren
RBAC hat Auswirkungen darauf, wie Objektmigration genehmigt wird und wie die neu migrierten Objekt-ACLs erstellt werden.
Der Migrationsvorgang verlässt sich auf SSH, um Befehle auf einem Remote-Grid auszuführen. Eigentlich migriert CA AppLogic® nur mit "--import" vom Remote-Grid zum lokalen Grid. Wenn ein Benutzer mit der Option "--Export" migriert, wendet CA AppLogic® SSH auf dem Remote-Grid an und migriert mit dem Befehl "--import".
Daraus ergibt sich, dass, wenn ein Objekt mit "--import" migriert wird, das sich ergebende neue Objekt dem Benutzer gehört, der den Migrationsbefehl auf dem lokalen Grid ausführt. Dieser Benutzer hat volle Zugriffsebenenrechte (full) auf dem entstehenden Objekt. Wenn jedoch ein Objekt mit "--export" migriert wird, dann gehört dem Benutzer auf dem Remote-Grid, der den Migrationsbefehl "--import" auf dem Remote-Grid ausführt, das neue Objekt und er verfügt über volle Zugriffsebenenrechte (full).
Objektmigration verlässt sich auf eine zwischen zwei Grids erstellte "Vertrauensbasis". Es gibt zwei unterschiedliche Methoden, solches "Vertrauen" herzustellen:
- Grid L (lokales Grid) hat einen Benutzer, dessen öffentlicher Schlüssel der von Grid R (Remote-Grid) ist, und Grid R hat einen Benutzer, dessen öffentlicher Schlüssel der von Grid L ist. In diesem Fall werden die öffentlichen/privaten Schlüsselpaare des Grid verwendet, um während des Migrationsvorgangs Remote-Befehle über SSH auszuführen. Dies ist die gebräuchlichste "Vertrauensbasis" und wird immer dann benötigt, wenn ein Objekt unter Verwendung der CA AppLogic®-Benutzeroberfläche migriert wird.
- Grid L und Grid R haben jeweils einen Benutzer, dessen öffentlicher Schlüssel dem privaten Schlüssel entspricht, der in SSH-Forwarding in einer vom ausführenden Benutzer auf dem lokalen Grid geöffneten Shell verwendet wird. In diesem Fall verlässt sich der Migrationsvorgang auf das SSH-Forwarding (zum Beispiel in einer PuTTY-Sitzung), um Remote-Befehle während des Migrationsvorgangs auszuführen.
Die untenstehende Tabelle zeigt mehrere unterschiedliche Szenarien, ihre Voraussetzungen und ihre Ergebnisse an. Zu Erklärungszwecken bezieht sich die Tabelle auf die folgenden Beispielbenutzer:
- Benutzer 'A' auf Grid L: der Benutzer auf dem lokalen Grid L, der den Migrationsbefehl ausführt.
- Benutzer 'B' auf Grid R - ein Benutzer auf dem Remote-Grid R mit dem gleichen öffentlichen Schlüssel wie der von Benutzer 'A'
- Benutzer 'TA' auf Grid L - dieser Benutzer hat den öffentlichen Schlüssel des Remote-Grid R und wird verwendet, um "Vertrauen" zwischen den Grids aufzubauen.
- Benutzer 'TB' auf Grid R - dieser Benutzer hat den öffentlichen Schlüssel des lokalen Grid L und wird verwendet, um "Vertrauen" zwischen den Grids aufzubauen.
Migrationsvorgang
|
Voraussetzungen
|
Ergebnisse
|
Migrieren Sie "--import" unter Verwendung von SSH-Schlüssel-Forwarding
|
- Benutzer 'A' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid L.
- Benutzer 'B' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid R.
- Benutzer 'B' hat Konfigurationszugriffsebenenrechte (configure) oder volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Die sich ergebende, auf Grid L erstellte Anwendung gehört Benutzer 'A', und dieser Benutzer hat volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Migrieren Sie "--import" unter Verwendung der von den öffentlichen/privaten Schlüsselpaaren des Grid aufgebauten "Vertrauensbasis".
|
- Benutzer 'A' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid L.
- Benutzer 'TB' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid R.
- Benutzer 'TB' hat Konfigurationszugriffsebenenrechte (configure) oder volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Die sich ergebende, auf Grid L erstellte Anwendung gehört Benutzer 'A', und dieser Benutzer hat volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Migrieren Sie "--export" unter Verwendung von SSH-Schlüssel-Forwarding
|
- Benutzer 'A' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid L.
- Benutzer 'A' hat Konfigurationszugriffsebenenrechte (configure) oder volle Zugriffsebenenrechte (full) auf der Anwendung.
- Benutzer 'B' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid R.
|
Die sich ergebende, auf Grid R erstellte Anwendung gehört Benutzer 'B', und dieser Benutzer hat volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Migrieren Sie "--export" unter Verwendung der vom öffentlichen/privaten Schlüsselpaar-Forwarding des Grid aufgebauten "Vertrauensbasis".
|
- Benutzer 'A' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid L.
- Benutzer 'A' hat Konfigurationszugriffsebenenrechte (configure) oder volle Zugriffsebenenrechte (full) auf der Anwendung.
- Benutzer 'TA' hat Konfigurationszugriffsebenenrechte (configure) oder volle Zugriffsebenenrechte (full) auf der Anwendung.
- Benutzer 'TB' hat app_developer- oder grid_administrator-Zugriffsebenenrechte auf Grid R.
|
Die sich ergebende, auf Grid R erstellte Anwendung gehört Benutzer 'TB', und dieser Benutzer hat volle Zugriffsebenenrechte (full) auf der Anwendung.
|
Copyright © 2013 CA.
Alle Rechte vorbehalten.
|
|