Skip to content

Superuser Access

Overview

At checkout the broker creates a temporary user with full SUPERUSER privileges and returns a connection command; at checkin it removes the user and all its privileges. Use this only when the highest level of access is genuinely required — break-glass, major migrations, or root-cause work that narrower privileges can’t perform.

Superuser is unrestricted server admin. Require an approval workflow on this profile, keep the expiration short, and prefer DBA Access or Role Grant Access where they suffice.

Before You Begin

Environment Variables

VariableNotes
BRITIVE_USERInjected — email; username derived (non-alphanumerics stripped)
svc_user, svc_passwordService account credentials
db_host, db_nameConnection details

Checkout / Checkin

Full scripts: postgres-adminaccess-checkout.sh · postgres-adminaccess-checkin.sh

# checkout — create SUPERUSER with a generated password
psql ... -c "CREATE USER \"$username\" PASSWORD '$generated' SUPERUSER;"
echo "psql -h $db_host -d $db_name -U $username"

# checkin — clean up owned objects then drop
psql ... <<SQL
REASSIGN OWNED BY "$username" TO "$svc_user";
DROP OWNED BY "$username";
DROP ROLE "$username";
SQL

Configure in Britive

Create the permission

Resource Manager → Resource Type Permissions → New Permission. Language = Shell. Paste both scripts. Declare svc_user, svc_password, db_host, db_name (BRITIVE_USER is system-defined).

Create a profile and policy

Create a profile with a short expiration (e.g. 30m). Add the permission. Add a policy that requires approval and assign members narrowly.

Verify

-- during checkout
SELECT rolsuper FROM pg_roles WHERE rolname = '<user>';   -- t
-- after checkin
SELECT 1 FROM pg_roles WHERE rolname = '<user>';          -- 0 rows

Troubleshoot

SymptomCauseFix
must be superuser to create superusersService account is not a superuserUse a superuser service account
DROP ROLE failsUser owns objectsConfirm the checkin REASSIGN/DROP OWNED ran

Next Steps

Last updated on