Cloud Control und Entwickler: Passt das zusammen?
Oracle bietet verschiedene Tools zur Verwaltung und zum Tuning an. Bis zum Oracle Release 12c/19c waren Database Express Console, der SQL Developer und natürlich Skripte die Mittel der Wahl. Mit 19c sind verschiedene Features aus der Database Express Console in das sehr mächtige Tool Oracle Cloud Control "umgezogen", das Tool Database Express Console gibt es ab Oracle 23c nicht mehr.
Eine Frage an die OEM Administratoren ist immer wieder: "Können nicht auch die Entwickler das Oracle Cloud Control nutzen, wenn es bereits vorhanden ist?"
Die Antwort ist meist: "Dann können die Entwickler viel zu viel sehen und die Datenbank kaputt machen".
Im Folgenden soll eine Beispiellösung gezeigt werden, bei der Entwickler nur die für ihre Datenbank notwendigen Privilegien erhalten.
Voraussetzungen
Was sollte dem Entwickler im Cloud Control erlaubt sein ?
Der Entwickler sollte entsprechend seiner Aufgaben bestimmte Tools nutzen – entweder mit Read Only oder mit Read Write Zugriff, hier eine Auswahl:
- Performance Home Page
- ASH, AWR, ADDM
- Performance Hub
- Advisor
- SQL Performance Analyzer
- SQL Access Advisor
- SQL Tuning Advisor
- SQL Tuning Sets erstellen
- Optimizer Statistiken anpassen
Was sollte dem Entwickler im Cloud Control nicht erlaubt sein (Auszug) ?
- Datenbankdateien / Tablespaces anpassen und ändern
- Parameter der Datenbank ändern
- Backup und Recovery ausführen
- Security Konfigurationen anpassen
- ...
In einer Testumgebung soll das gezeigt werden:
1. Ausgangspunkt ist eine CDB names PROD_DEV mit zwei PDB's.
2. Es existieren Named Credentials für Datenbank und Host,
diese sind als "View Credential" in der Rolle PROD_ROLE hinterlegt.
3. Der Benutzer PROD wird angelegt. Er kann anfangs nach der Anmeldung noch keinen Target sehen.
$ emcli create_user
-name="PROD_DEV"
-password="<Password>"
-roles="public;EM_USER;PROD_ROLE"
Target Privilegien zuweisen
Zunächst betrachten wir die Unterschiede zwischen Target Privilegien und Target Instance Privilegien.
Target Privilegien:
Mit diesen Privilegien können Administratoren die verschiedene Management Funktionen (oft zusätzlich mit dem Schlüsselwort any ) im OEM ausführen, z.B. Targets hinzufügen, EM Monitoring,
Operator any Targets.
Target Instance Privilegien:
Für eine Datenbank gibt es beispielsweise 163 verfügbare Target Instance Privilegien für die Ausführung unterschiedlichster Aufgaben, z.B. die Verwaltung von Datenbankparametern, Datenfiles und weitere. Der Benutzer PROD_DEV darf seine Datenbank PROD sehen, deshalb werden ihm nur die entsprechenden Target Instance Privilegien für den ROOT Container und die beiden PDBs zugewiesen.
Erster Versuch:
Das vordefinierte Privileg "Database Application Developer" wird in der grafischen Oberfläche ausgewählt.
Wie sieht das Ergebnis nach der Zuweisung als "Application Developer" aus?
Wie man sieht, sind die Privilegien nicht ausreichend!
Im Beispiel kann der Application Developer folgendes benutzen:
- Performance Home Page aber
- kein ADDM Report nutzbar
- kein ASH Report nutzbar
- Performance Hub (teilweise nutzbar)
Aber ausgewählte Seiten im Cloud Control sind noch sichtbar, die der Application Developer nicht sehen sollte, z.B.:
- Schema Objekte
- Automatic Maintenance Tasks
Zweiter Versuch:
Der Benutzer PROD_DEV erhält das vordefiniertem Privileg "Database Application DBA"
Damit kann der Benutzer schon mehr nutzen (vielleicht zu viel), weil die feingranulare Auswahl der Privilegien immer noch fehlt.
Ein Application DBA kann nutzen:
- Performance Home
- ADDM Report nutzbar
- ASH Report nutzbar
- Performance Hub vollständig nutzbar
- SQL Performance Analyzer HOME teilweise nutzbar
- SQL Tuning Sets teilweise nutzbar
Im dritten Versuch wird nun eine feingranularere Lösung gezeigt:
Um eine benutzerspezifische Aufgabe grafisch zu konfigurieren, wären übersichtliche Einzelprivilegien mit ihren Anzeigename (Display Name) wünschenswert. Allerdings hilft ein Blick in die Dokumentation Cloud Control Security Guide (Appendix - C ) nicht wirklich weiter. Man findet nur 19 Privilegien (statt der vorhandenen ca. 163 Privilegien). Deshalb probieren wir es mit der Kommandozeile, mit der folgenden emcli Abfrage im OEM lassen sich die Privilegien anzeigen:
$ emcli get_supported_privileges -type=TARGET
Privilege Name Privilege Scope Security Class . . .
DB_PERFORMANCE_HOME_VIEW Resource TARGET . . .
DB_AWR_VIEW Resource TARGET . . .
DB_SPA_ADMIN Resource TARGET . . .
CONNECT_READONLY_TARGET Resource TARGET . . .
. . .
Bei genauer Betrachtung gibt es hier die Privilegien, die für uns interessant sind, z.B. DB_PERFORMANCE_HOME_VIEW, DB_PERFORMANCE, DB_AWR, DB_ADDM, DB_SQL_TUNING_SET, DB_SQLMONITOR mit dem zusätzlichen Privileg View oder Admin.
Mit Hilfe dieser Information ist es nun möglich, einen Benutzer spezielle Aufgaben zuzuweisen. Das geht am einfachsten wieder mit emcli.
Beispiel 1:
Der Entwickler soll folgende Aufgaben ausführen:
- Performance Home Page nutzen
- AWR erstellen und ansehen
- ADDM ausführen und ansehen
Achtung: "Connect Target" ist bei einer benutzerdefinierten Konfiguration notwendig, in den vordefinierten umfangreichen Privilegien nicht.
$ emcli grant_privs
-name="PROD_DEV"
-privilege="DB_AWR_VIEW;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="DB_ADDM_VIEW;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="DB_PERFORMANCE_HOME_VIEW;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="CONNECT_TARGET;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
Hier ist die möglichen Aktionen für den angemeldeten Entwickler im Cloud Control erkennbar:
Beispiel 2:
Der Entwickler soll nur SQL Tuning mit folgenden Tools durchführen können:
- SQL Monitoring
- SQL Tuning Advisor
- SQL Tuning Sets
$ emcli grant_privs
-name="PROD_DEV"
-privilege="DB_SQL_ADVISOR;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="DB_TUNING_ADVISOR;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="DB_TUNING_SET_ADMIN;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
-privilege="CONNECT_TARGET;TARGET_NAME=PROD:TARGET_TYPE=oracle_database"
Hier sind die möglichen Aktionen für den angemeldeten Entwickler im Cloud Control erkennbar:
Zusammenfassung:
In diesem Blogeintrag wurde gezeigt, dass ein Entwickler OEM Cloud Control für ausgewählte Aufgaben nutzen kann, die vom OEM Administrator konfiguriert werden.
Die grafischen Oberfläche verfügt über vordefinierte Privilegien, aber diese spiegeln nicht immer die gewünschten Aufgaben wieder.
Aber wie im Beispiel gezeigt, lassen sich diese Aufgaben mit dem OEM Kommandozeilen-Tool emcli lösen.
Kommentare
Keine Kommentare