Prima di iniziare

Ti serve:

• Un'installazione di Databases for PostgreSQL con la password di amministratore impostata.
• Un utente del database per la tua applicazione, creato tramite l'interfaccia utente, la CLI o l'API.
• PgBouncer 1.11.0 o versione successiva, che supporti l'autenticazione SCRAM, installata su un'infrastruttura sotto il vostro controllo. Se si intende utilizzare le istruzioni preparate a livello di protocollo in modalità "transaction pooling", utilizzare PgBouncer 1.21.0 o versioni successive.
• Un cliente di psql.
• Informazioni sulla connessione di distribuzione:
  • Nome host e porta, dalle [stringhe di connessione]...
  • Certificato CA, recuperato tramite ibmcloud cdb deployment-cacert.

Il supporto per " pgbouncer_lookup " viene gradualmente esteso a tutte le installazioni. Per verificare che la tua distribuzione disponga di tale funzione, accedi a psql con l'account admin ed esegui \df public.pgbouncer_lookup. Se il risultato è vuoto, la tua distribuzione riceverà la funzione con un prossimo aggiornamento di manutenzione.

Creazione di un utente dedicato all'autenticazione

PgBouncer auth_query viene eseguito con un unico ruolo di accesso designato, ovvero. auth_user Crea un ruolo da utilizzare esclusivamente a questo scopo. Un ruolo dedicato che non possiede dati e non esegue nessun’altra operazione rappresenta la scelta basata sul principio del privilegio minimo.

Accedi a psql come utente admin, quindi crea il ruolo e assegnagli l'autorizzazione pgbouncer_auth:

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

Il ruolo " pgbouncer_auth " comporta un unico privilegio: l'autorizzazione a eseguire la funzione " pgbouncer_lookup ". L'utente admin possiede il gruppo pgbouncer_auth con l'opzione "amministratore", pertanto sei tu stesso a concedere e revocare l'appartenenza al gruppo. È anche possibile creare l'utente con l' ibmcloud cdb user-create, se si desidera che compaia nelle credenziali del servizio; tuttavia, gli utenti creati in questo modo fanno parte del gruppo ibm-cloud-base-user e possono creare utenti e database, il che va oltre le esigenze dell'utente di autenticazione.

Concedere l' pgbouncer_auth e solo all'utente autorizzato. Qualsiasi membro del ruolo può leggere i verificatori di password memorizzati degli altri utenti del database; pertanto, ogni nuovo membro amplia la portata delle conseguenze derivanti dalla compromissione di una credenziale.

Per disattivare un utente autorizzato, revocare la sua appartenenza:

REVOKE pgbouncer_auth FROM pool_auth;

Configurazione PgBouncer

Per connettersi a un'istanza di Databases for PostgreSQL sono necessarie le seguenti impostazioni di PgBouncer:

• auth_type = scram-sha-256, poiché le distribuzioni memorizzano i verificatori di password dell' SCRAM-SHA-256.
• auth_query = SELECT * FROM public.pgbouncer_lookup($1), poiché PgBouncer's per impostazione predefinita auth_query legge direttamente pg_authid e gli utenti del database non possono accedervi.
• TLS lato server, poiché le distribuzioni accettano solo connessioni TLS. Imposta server_tls_sslmode = verify-full e salva il certificato che hai recuperato tramite ibmcloud cdb deployment-cacert nel percorso specificato in server_tls_ca_file.

PgBouncer legge le credenziali del proprio auth_user da auth_file; pertanto, in questa configurazione, userlist.txt contiene solo le credenziali di auth_user. Ogni altro utente effettua la risoluzione tramite auth_query. Limitare i permessi del file al proprietario del processo “ PgBouncer ”, ad esempio con la modalità 0600.

"pool_auth" "<POOL_AUTH_PASSWORD>"

Una configurazione minima completa, in cui <HOSTNAME> e <PORT> derivano dalle stringhe di connessione:

[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

Non impostare " auth_dbname = postgres". La funzione di ricerca non è installata nel database " postgres ". Lasciare il parametro auth_dbname non impostato, in modo che la query di autenticazione venga eseguita nel database a cui si connette il client. I database creati in seguito includono automaticamente questa funzione.

Per le descrizioni di ogni impostazione, consultare il manuale di riferimento sulla configurazione di PgBouncer.

Verifica della configurazione

1. Verifica che la ricerca identifichi uno degli utenti del tuo database. Accedi a psql con l' admin e ed esegui:

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

   Il risultato è una riga contenente " can_authenticate = t". La query è stata scritta in modo tale che il prompt per l'inserimento della password non venga visualizzato. Gli utenti con accesso riservato al servizio, tra cui admin, non restituiscono alcuna riga.

2. Accedi tramite PgBouncer come utente del database:

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

   Se la connessione va a buon fine, PgBouncer autentica correttamente gli utenti tramite auth_query.

3. Modifica la password dell'utente del database, quindi riconnettiti tramite PgBouncer utilizzando la nuova password:

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

   La nuova password è attiva da subito. Non è necessario riavviare PgBouncer, ricaricare la pagina o modificare l' userlist.txt.

Come funziona il modello di sicurezza

La funzione pgbouncer_lookup fornisce solo le informazioni necessarie a PgBouncer per l'autenticazione.

• La funzione viene eseguita con SECURITY DEFINER e un search_path fissato, e legge pg_catalog.pg_authid per conto tuo. L'accesso diretto a pg_authid e pg_shadow rimane bloccato.
• Restituisce i verificatori SCRAM sottoposti a hash, mai password in chiaro.
• Vengono risolti solo i ruoli autorizzati ad effettuare l'accesso. Gli utenti riservati al servizio, come admin e gli utenti interni di replica e operazioni, non vengono mai risolti.
• Se il VALID UNTIL è passato, la funzione restituisce una password NULL, quindi l'autenticazione fallisce e la scadenza della password rimane in vigore.
• L'autorizzazione all'esecuzione della funzione è stata revocata a PUBLIC e concessa esclusivamente a admin e ai membri di pgbouncer_auth.

PgBouncer's Per impostazione predefinita, il comando auth_query legge direttamente il file pg_authid , cosa che gli utenti del database non possono fare. In questa situazione, la documentazione di PgBouncer consiglia invece di richiamare una funzione SECURITY DEFINER tramite un utente non superutente. La funzione " pgbouncer_lookup " è quella funzione, da cui sono esclusi gli utenti riservati del servizio.

Limitazioni e considerazioni

• PgBouncer non aumenta l' max_connections e della tua distribuzione. Regola le dimensioni di default_pool_size in modo che il numero totale di connessioni al server provenienti da tutte le tue istanze di PgBouncer rimanga entro il limite di connessioni. Se raggiungi il limite, consulta la sezione " Aumentare il numero massimo di connessioni ".
• L'utente admin non riesce ad autenticarsi tramite auth_query. Per le attività amministrative, effettuare l'accesso come admin direttamente all'ambiente di distribuzione, non tramite PgBouncer.
• Il database " postgres " non dispone della funzione di ricerca, quindi non impostare mai auth_dbname = postgres``.
• Nella modalità di raggruppamento delle transazioni (pool_mode = transaction), lo stato della sessione — quali le variabili SET , le tabelle temporanee, i blocchi di tipo advisory e i canali LISTEN — non viene trasferito da una transazione all'altra. Le istruzioni preparate a livello di protocollo richiedono max_prepared_statements e PgBouncer 1.21.0 o versioni successive. Per ulteriori informazioni, consultare la sezione " Funzionalità di PgBouncer ".
• Durante un aggiornamento alla versione principale in loco, l'ambiente di distribuzione subisce un breve periodo di inattività e le connessioni aperte vengono interrotte (SQLSTATE 57P01). PgBouncer ristabilisce automaticamente le connessioni al server, ma le applicazioni devono riprovare a eseguire le transazioni interrotte e ripreparare le istruzioni.
• Gli utenti con diritti di sola lettura non possono connettersi all'endpoint primario. Per unificare le connessioni, aggiungi una voce separata " [databases] " che punti alla tuareplica in sola lettura.

Passi successivi

• Gestione delle connessioni
• Ottenere le stringhe di connessione
• Gestione di utenti, ruoli e autorizzazioni
• PgBouncer Guida alla configurazione