How to set default owner of objects created by EF core code first using postgresql with database credential rotation? - postgresql

Question

I am connecting from a containerized asp.net core 3.1 application running code-first EF core to an Amazon Aurora instance with PostgreSQL compatibility and wish to perform database credential rotation. I have set up a role representing the database owner, and a role representing the current valid login credentials that we will expire and replace with new credentials.
I have followed the suggestion from this blog post:
http://davidhollenberger.com/2017/03/16/postgres-credential-rotation/, which is essentially:
create role db_owner nologin;
create role foo_a with encrypted password ...;
grant db_owner to foo_a;
alter role foo_a set role db_owner;
I understand that whenever foo_a logs in to postgres, their default role is set to db_owner. If I log into the database using psql this seems to work consistently.
However, with EF Core, when connecting using the foo_a database credentials migrating the database to a new schema the object owner of new objects is listed as foo_a.
Example:
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------------------------------------
public | test | table | foo_a
I expected the owner to be db_owner, since foo_a should always log in as db_owner.
Is there something I can do, either from EF Core, or when setting up the postgresql database that will allow us to set default ownership for all objects created by the user to the role group representing our database owner? I do not wish to make these temporary accounts some kind of 'superuser' for the instance, since we have multiple tenants in our database instance, instead I wish to have something similar to a 'dbo' role that has ownership of the database and the temporary users will always connect as the 'dbo' role.

Answer 1

Pooled connections are reset using the DISCARD ALL statement, which in turn resets the session and current user identifiers to be the originally authenticated user name. In other words:
Pooled connection reset (https://www.npgsql.org/doc/performance.html#pooled-connection-reset)
Runs DISCARD ALL (https://www.postgresql.org/docs/current/sql-discard.html)
Which in turn runs SET SESSION AUTHORIZATION DEFAULT (https://www.postgresql.org/docs/8.1/sql-set-session-authorization.html)
During a db migration, this sets the owner of any objects created to the user instead of the dbo role that he automatically inherits by ALTER ROLE... SET ROLE...
Options to resolve this issue will depend on your needs. Here are a few options we considered to resolve this question:
Make the db owner a member of the db user. Supplement this with a script that runs as part of our database/user provisioning and rotation strategy that sets all object ownership to the owner instead of the user. This requires zero code changes for the .net core app, but does seem messy from the perspective of object ownership.
In .Net use an IDBCommandInterceptor to set the appropriate role when we reuse a connection from the pool. This is a more invasive solution affecting your .net core project, but if your requirements involve credential rotation for one or only a few projects it may be practical.
Append the option No reset on close=true to the npgsql connection string. However, be aware that this risks leaking session state if you are using connection pooling. Reference: https://www.npgsql.org/doc/connection-string-parameters.html#performance
Other options, such as running a proxy are also worthy of consideration.