Schlagwort-Archive: RDS

Der Export von Rollen bei PostgreSQL auf AWS RDS – leider ohne Passwort-Hashes

Schreibe eine Antwort

Ich hatte mir zum Ziel gesetzt, die Daten einer PostgreSQL-RDS zu einer anderen RDS migrieren zu wollen – und das via SQL. Daher habe ich versucht, die Metadaten für die Rollen zu generieren. Normalerweise würde ich das folgendermaßen machen:

$ pg_dumpall -h myrds.eu-central-1.rds.amazonaws.com -U rdsmaster
 -r -f dumpall_roles.sql

Leider klappte das nicht so, weil:

pg_dumpall: error: query failed: ERROR:  permission denied for table pg_authid
pg_dumpall: error: query was: SELECT oid, rolname, rolsuper, rolinherit, rolcreaterole, rolcreatedb, rolcanlogin, rolconnlimit, rolpassword, rolvaliduntil, rolreplication, rolbypassrls, pg_catalog.shobj_description(oid, 'pg_authid') as rolcomment, rolname = current_user AS is_current_user FROM pg_authid WHERE rolname !~ '^pg_' ORDER BY 2

AWS sperrt also den Zugriff auf die Tabelle pg_authid im Catalog. Auch eine Nachfrage beim AWS Support hat mir nur eingeschränkt geholfen.

I would like to kindly inform you that RDS PostgreSQL doesn’t support access on ‘pg_authid’ table. Since RDS is a managed service, for platform stability, RDS don’t support full permission for all system relations. […] The workaround is to supply “–no-role-passwords” to pg_dumpall command.

Na danke. Somit muss ich nun alle Passwörter nachträglich manuell setzen. Klappt natürlich nur, wenn man selbst die Hoheit über die Passwörter hat.

Funktionen, die man bei AWS RDS nicht einsetzen kann – Teil 1

Schreibe eine Antwort

Ich darf in den letzten Monaten beruflich häufiger Datenbanken aus Rechenzentren nach AWS RDS migrieren. Ich gebe gerne zu, dass RDS ein großartiges Framework ist, durch das man sich nicht mehr um Installation, Konfiguration, Backup, Restore und Patching einer Datenbank kümmern muss und es dadurch bedeutend einfacher ist, Software einzusetzen, die man nicht so sehr im Detail kennt. Damit RDS so nutzbar ist, hat AWS eine eigene Konfektionierung entwickelt. Einige Funktionen sind somit leider nicht verfügbar. Da ich während meiner Arbeit immer wieder mal auf derartige Hürden stoße, möchte ich gerne über diese berichten.

Oracle

Oracle ist meiner persönlichen Meinung nach das beste relationale Datenbankmanagementsystem – jedoch auch das teuerste. Daher sollte man meiner Meinung nach auch wirklich nur Oracle einsetzen, wenn man einige Besonderheiten davon nutzen möchte.

Dateisystemschnittstellen

In eine Oracle-RDS kann man leider keine NFS-Shares von EFS oder anderen Storage mounten. Dadurch gibt es nur zwei Wege in die RDS herein und heraus:

  1. Nutzung eines S3-Buckets als Intermediate-Storage
    Upload nach S3, Download in RDS / Upload nach S3, Download nach App-Server, Schnittstellensystem, etc.
  2. Direktkopie via Datenbanklink und DBMS_FILETRANSFER. Dazu muss jedoch die andere Quelle eine Oracle-Datenbank haben und ist daher nicht zwingend geeignet.

Ich arbeite mit Schnittstellensystemen, die Dateien von oder zur Datenbank über NFS oder SMB direkt übertragen möchten. Das ist hier leider nicht möglich.

PostgreSQL

Authentifizierung mit Zertifikaten

Bei einem Projekt wollten wir eine Authentifizierung über Zertifikate mit der Datenbank einrichten. Dies entfällt leider, da man bei RDS weder die pg_hba.conf direkt bearbeiten, noch die SSL-Zertifikate mit eigenen ersetzen kann.

Was soll ich tun, wenn ich auf derartige Probleme stoße?

Tja, schwierig. Wenn man auf derartige Probleme stößt, ist die eingesetzte Software eigentlich nicht “cloud-ready”. Als Alternative kann man bspw. Oracle oder PostgreSQL manuell auf einer EC2 installieren. Dadurch gehen jedoch die Automatisierungseffekte verloren, die einem die Administration so signifikant vereinfachen.

Besonderheit bei der Rollenadministration beim Einsatz von Oracle bei AWS RDS

Schreibe eine Antwort

Bei einem Import eines Datapump-Dumps in eine Oracle-RDS-Umgebung fiel neulich folgende Problematik auf:

Ich hatte eine Rolle, die ich nicht granten konnte und das, obwohl ich mit dem RDS-Master-User arbeite. Es zeigte sich, dass ich keine GRANTs verteilen konnte, weil mir die ADMIN OPTION für diese Rolle fehlte. Leider habe ich die genaue Fehlermeldung nicht mehr parat. Da ich bei RDS auch keine SYS-Privilegien besaß, konnte ich nicht die ADMIN OPTION nachträglich setzen.

Zur Validierung habe ich erneut eine Rolle angelegt und gesehen, dass ich auch automatisch die ADMIN OPTION bei Erstellung erhalte.

CREATE ROLE TESTROLE_A NOT IDENTIFIED;

-- Grantees of TESTROLE_A
GRANT TESTROLE_A TO DB_ADMIN WITH ADMIN OPTION;

Somit bin ich zum Ergebnis gekommen, dass die Rolle von Datapump leider allgemein ohne einen einzigen Administrator importiert wurde und somit zwar allgemein nutzbar, aber nicht mehr administrierbar ist. Da man bei AWS nicht an die SYS-Privilegien herankommt und zur Modifizierung der Rolle die rdsadmin.rdsadmin_util.grant_sys_object-Prozedur nicht hilfreich ist, blieb mir nichts übrig, als manuell die Rolle zu löschen und erneut anzulegen.