A query against a foreign table can look like an ordinary PostgreSQL operation. Behind that table, postgres_fdw may open a second database connection using a username and password stored in a user mapping. This boundary is easy to miss during access review because the local role and the remote account are different identities with different privileges.
User mappings hold connection identity
PostgreSQL's CREATE USER MAPPING command associates a local role with connection information for a foreign server. For postgres_fdw, connection options such as user and password belong in the user mapping or a service file rather than directly in the foreign server definition. Documentation notes that only superusers may connect to foreign servers without password authentication, so non-superuser mappings normally need an explicit secret.
The local role executes the SQL. The remote account authorizes the remote action. A local read-only user may still reach a remote account with write access if the mapping is wrong. Review both sides of every foreign table path.
Minimize the mapping
Create one local role and remote account for each workload that needs foreign data access. Do not reuse a remote superuser for reporting jobs. Grant only the remote schemas and tables the application reads, and use read-only sessions where the foreign data wrapper supports them.
Some deployments use a single mapping for many local users. That design can be convenient, but it removes the remote account's ability to distinguish users. If audit records must show the originating application, use separate mappings even when the remote privileges are similar.
Protect the stored secret
User mappings are database objects. Their options may be visible through catalog views to roles with sufficient access. Treat any password stored in a mapping as a database credential, not as an encrypted vault secret. Restrict catalog access, monitor administrative queries that reveal mapping metadata, and rotate the remote password on a schedule that matches the application change process.
For approved workloads, consider a service file or an external credential provider when the foreign data wrapper supports it. The goal is to reduce plaintext credential persistence while keeping startup and failure behavior predictable.
Audit the complete path
List foreign servers, foreign data wrappers, user mappings, and foreign tables. For each table, record the local owner, local grants, remote user, remote database, and remote grants. Test a query as a non-superuser and verify that current_user is local while the remote account is the one in the mapping.
Review connection encryption, certificate validation, DNS resolution, and network policy. A foreign server that resolves to a different address after a DNS change can redirect credentials and data. Pin the expected host and certificate policy where the deployment supports it.
Test failure and cleanup
Disable a test mapping and confirm the local query fails without leaking remote credentials. Remove a local user and check whether an orphaned mapping remains. Rotate the remote password and confirm that the old value fails everywhere. Delete mappings that no longer support an active foreign table.
Foreign data wrappers extend PostgreSQL's data plane across systems, but they do not merge the authorization models. The local grant is only half of the decision. A reliable review follows the query into the user mapping, verifies the remote account, and checks which data the second identity can actually reach.