Vorbereitende Schritte

Sie benötigen Folgendes:

• Eine Databases for PostgreSQL-Bereitstellung mit festgelegtem Administratorpasswort.
• Ein Datenbankbenutzer für Ihre Anwendung, der über die Benutzeroberfläche, die Befehlszeilenschnittstelle(CLI)oder die API angelegt wurde.
• PgBouncer 1.11.0 oder höher, das die SCRAM-Authentifizierung unterstützt, installiert auf einer Infrastruktur, die Sie selbst verwalten. Wenn Sie vorhaben, vorbereitete Anweisungen auf Protokollebene im Transaktions-Pooling-Modus zu verwenden, nutzen Sie PgBouncer ( 1.21.0 ) oder eine neuere Version.
• Ein Kunde psql.
• Ihre Verbindungsdaten für die Bereitstellung:
  • Hostname und Port aus den [Verbindungszeichenfolgen]...
  • CA-Zertifikat, abgerufen mit ibmcloud cdb deployment-cacert.

Die Unterstützung für pgbouncer_lookup wird derzeit in allen Bereitstellungen eingeführt. Um zu überprüfen, ob Ihre Bereitstellung über die Funktion verfügt, stellen Sie eine Verbindung mit als psql her admin und führen Sie aus \df public.pgbouncer_lookup. Wenn das Ergebnis leer ist, erhält Ihre Bereitstellung die Funktion mit einem bevorstehenden Wartungsupdate.

Erstellen eines dedizierten Authentifizierungsbenutzers

PgBouncer wird auth_query als eine bestimmte Anmelderolle ausgeführt, deren auth_user. Erstellen Sie eine Rolle, die ausschließlich für diesen Zweck verwendet wird. Eine dedizierte Rolle, die keine Daten verwaltet und keine anderen Prozesse ausführt, ist die Lösung mit den geringsten Berechtigungen.

Melden Sie sich psql als Benutzer admin an, erstellen Sie dann die Rolle und weisen Sie ihr folgende Berechtigungen zu pgbouncer_auth:

CREATE ROLE pool_auth WITH LOGIN PASSWORD '<POOL_AUTH_PASSWORD>';
GRANT pgbouncer_auth TO pool_auth;

Die Rolle pgbouncer_auth verfügt über eine einzige Berechtigung: die Erlaubnis, die Funktion pgbouncer_lookup auszuführen. Der Benutzer admin verfügt pgbouncer_auth über die Administratorrechte, sodass Sie die Mitgliedschaft selbst gewähren und widerrufen können. Sie können den Benutzer auch mit anlegen, wenn ibmcloud cdb user-create er in Ihren Service-Anmeldedaten erscheinen soll. Allerdings gehören auf diese Weise angelegte Benutzer zur Gruppe ibm-cloud-base-user und können Benutzer und Datenbanken anlegen – was über die Anforderungen des Authentifizierungsbenutzers hinausgeht.

Erteilen Sie die Berechtigung ausschließlich pgbouncer_auth dem dafür vorgesehenen autorisierten Benutzer. Jedes Mitglied dieser Rolle kann die gespeicherten Passwort-Verifizierer Ihrer anderen Datenbankbenutzer einsehen, sodass jedes weitere Mitglied die Auswirkungen einer kompromittierten Anmeldeinformation vergrößert.

Um einen Authentifizierungsbenutzer zu deaktivieren, widerrufen Sie dessen Mitgliedschaft:

REVOKE pgbouncer_auth FROM pool_auth;

PgBouncer konfigurieren

Die folgenden PgBouncer-Einstellungen sind erforderlich, wenn eine Verbindung zu einer Databases for PostgreSQL-Bereitstellung hergestellt wird:

• auth_type = scram-sha-256, da in den Bereitstellungen Passwortprüfer für SCRAM-SHA-256 gespeichert sind.
• auth_query = SELECT * FROM public.pgbouncer_lookup($1), da PgBouncer's standardmäßig direkt pg_authid auth_query gelesen wird und Ihre Datenbankbenutzer es nicht lesen können.
• Serverseitiges TLS, da die Bereitstellungen ausschließlich TLS-Verbindungen akzeptieren. Legen Sie fest und speichern Sie das Zertifikat server_tls_sslmode = verify-full, das Sie mit abgerufen haben, unter ibmcloud cdb deployment-cacert dem Pfad, den Sie in festgelegt haben server_tls_ca_file.

PgBouncer Liest die eigenen Anmeldedaten aus auth_user``auth_file, daher enthält userlist.txt in dieser Konfiguration ausschließlich die Anmeldedaten für auth_user. Jeder zweite Nutzer löst das Problem über auth_query. Beschränken Sie die Dateiberechtigungen auf den Prozessverantwortlichen PgBouncer, beispielsweise mit dem Modus 0600.

"pool_auth" "<POOL_AUTH_PASSWORD>"

Eine vollständige Minimal-Konfiguration, bei der <HOSTNAME> und aus Ihren Verbindungszeichenfolgen <PORT> stammen:

[databases]
ibmclouddb = host=<HOSTNAME> port=<PORT> dbname=ibmclouddb
[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
auth_user = pool_auth
auth_query = SELECT * FROM public.pgbouncer_lookup($1)
server_tls_sslmode = verify-full
server_tls_ca_file = /etc/pgbouncer/ca-certificate.crt
pool_mode = session
max_client_conn = 200
default_pool_size = 20

Nicht festlegen auth_dbname = postgres. Die Suchfunktion ist nicht in der Datenbank postgres installiert. Lassen Sie den Wert auf unset auth_dbname gesetzt, damit die Authentifizierungsabfrage in der Datenbank ausgeführt wird, mit der der Client verbunden ist. Datenbanken, die Sie später erstellen, enthalten diese Funktion automatisch.

Beschreibungen aller Einstellungen finden Sie in der Konfigurationsreferenz zu PgBouncer.

Einrichtung überprüfen

1. Stellen Sie sicher, dass die Abfrage einen Ihrer Datenbankbenutzer ergibt. Verbinden Sie sich mit als psql admin und führen Sie Folgendes aus:

   SELECT usename, passwd IS NOT NULL AS can_authenticate
     FROM public.pgbouncer_lookup('<APP_USERNAME>');
   

   Das Ergebnis ist eine Zeile mit can_authenticate = t. Die Abfrage ist so formuliert, dass die Passwortüberprüfung nicht angezeigt wird. Für den Dienst reservierte Benutzer, einschließlich admin, liefern keine Zeilen zurück.

2. Stellen Sie als Datenbankbenutzer eine Verbindung über PgBouncer her:

   psql "host=127.0.0.1 port=6432 dbname=ibmclouddb user=<APP_USERNAME>"
   

   Wenn die Verbindung erfolgreich hergestellt wird, authentifiziert PgBouncer Benutzer korrekt über auth_query.

3. Ändern Sie das Passwort des Datenbankbenutzers und stellen Sie anschließend über PgBouncer mit dem neuen Passwort erneut eine Verbindung her:

   ibmcloud cdb user-password <DEPLOYMENT_NAME_OR_CRN> <APP_USERNAME> <NEW_PASSWORD>
   

   Das neue Passwort ist sofort gültig. Es ist kein Neustart, kein Neuladen und keine Änderung userlist.txt von PgBouncer erforderlich.

So funktioniert das Sicherheitsmodell

Die Funktion pgbouncer_lookup gibt nur die Informationen preis, die PgBouncer für die Authentifizierung benötigt.

• Die Funktion wird mit und SECURITY DEFINER einem angehefteten search_path ausgeführt und liest pg_catalog.pg_authid in Ihrem Namen. Der direkte Zugriff auf und pg_authid bleibt pg_shadow gesperrt.
• Es werden gehasht SCRAM-Verifizierer zurückgegeben, niemals Passwörter im Klartext.
• Es werden nur Rollen aufgelöst, die sich anmelden dürfen. Für den Dienst reservierte Benutzer, wie z. B. admin sowie die internen Replikations- und Betriebsbenutzer, werden niemals aufgelöst.
• Liegt der Zeitstempel VALID UNTIL einer Rolle in der Vergangenheit, gibt die Funktion ein NULL-Passwort zurück, sodass die Authentifizierung fehlschlägt und die Passwortablaufregel weiterhin durchgesetzt wird.
• Die Berechtigung zum Ausführen der Funktion wird von entzogen und PUBLIC ausschließlich sowie admin den Mitgliedern von gewährt pgbouncer_auth.

PgBouncer's default lässt sich direkt pg_authid auth_query auslesen, was Ihren Datenbankbenutzern nicht möglich ist. In diesem Fall empfiehlt PgBouncer Dokumentation das, stattdessen eine Funktion SECURITY DEFINER über einen Nicht-Superuser aufzurufen. Die Funktion pgbouncer_lookup ist jene Funktion, wobei die für den Dienst reservierten Benutzer ausgeschlossen sind.

Einschränkungen und zu beachtende Punkte

• PgBouncer verursacht keine Erhöhung der. Ihrer Bereitstellung max_connections. Stellen Sie sicher default_pool_size, dass die Gesamtzahl der Serververbindungen aller Ihrer PgBouncer-Instanzen innerhalb des Verbindungslimits bleibt. Wenn Sie das Limit erreichen, lesen Sie den Abschnitt Erhöhen der maximalen Anzahl an Verbindungen.
• Der Benutzer admin kann sich nicht über auth_query … authentifizieren. Für Verwaltungsaufgaben stellen Sie eine direkte admin Verbindung zur Bereitstellung her, nicht über PgBouncer.
• Die Datenbank postgres verfügt nicht über die Suchfunktion, daher sollten Sie niemals … festlegen auth_dbname = postgres.
• Im Transaktions-Pooling-Modus (pool_mode = transaction) werden Sitzungszustände wie SET Variablen, temporäre Tabellen, Advisory-Locks und Kanäle LISTEN nicht zwischen Transaktionen übertragen. Vorbereitete Anweisungen auf Protokollebene erfordern PgBouncer ( 1.21.0max_prepared_statements ) oder eine neuere Version. Weitere Informationen finden Sie unter PgBouncer-Funktionen.
• Während eines In-Place-Upgrades auf eine neue Hauptversion kommt es bei Ihrer Bereitstellung zu einer kurzen Ausfallzeit, und offene Verbindungen werden beendet (SQLSTATE 57P01). PgBouncer stellt die Serververbindungen automatisch wieder her, Ihre Anwendungen müssen jedoch unterbrochene Transaktionen erneut versuchen und Anweisungen neu vorbereiten.
• Benutzer mit Lesezugriff können keine Verbindung zum primären Endpunkt herstellen. Um die Verbindungen zu bündeln, fügen Sie einen separaten Eintrag [databases] hinzu, der auf Ihreschreibgeschützte Replik verweist.

Nächste Schritte

• Verbindungen verwalten
• Verbindungszeichenfolgen abrufen
• Benutzer, Rollen und Berechtigungen verwalten
• PgBouncer Konfigurationshandbuch