Privilege model
You get a managed elevated role, not superuser, and not host access. What that role can do, what it cannot, and why each boundary is where it is.
You get a managed elevated role: the most privileged role on your service, and not a superuser. It can create schemas and roles, install approved extensions and tune an allowlisted set of parameters.
Every boundary below exists for a stated reason, and each one buys something specific.
What you get
- create schemas and roles, and grant within them
- install extensions from the supported catalogue
- tune an allowlisted set of parameters within plan-derived bounds
- read the statistics and monitoring views, through
pg_monitorandpg_read_all_stats
pg_read_all_stats is worth knowing about: it means your role sees every session's current
statement in pg_stat_activity, not only its own. That is what makes "which query is holding the
lock" answerable.
What you do not get
| Not granted | Why |
|---|---|
| PostgreSQL superuser | Superuser can read and write server-side files and load arbitrary code, which reaches outside the tenant boundary |
| Host or shell access | The isolation model depends on nothing inside the service being able to leave it |
CREATEDB | Withheld so the published database limit is enforced rather than merely documented |
REPLICATION | Physical replication slots and base backups are the platform's, and the backup chain depends on them |
BYPASSRLS | A role that can ignore row-level security defeats any policy you write |
| Backup repository credentials | The database runtime never holds them, so a compromised database cannot delete its own backups |
CREATEROLE is granted, which is why the role count is published as a guideline rather than a
limit. We are not going to print a number and imply enforcement we do not have.
Check what your role holds
SELECT rolsuper, rolcreatedb, rolcreaterole, rolreplication, rolbypassrls
FROM pg_roles
WHERE rolname = current_user;One true and four false. rolcreaterole is the true one.
The isolation boundary
Each service runs as its own user, in its own cgroup, on its own filesystem subtree. From inside a service:
- no path reaches outside its own volume
- no route reaches the management network
- no host privilege is obtainable
- killing its PostgreSQL process affects nothing else on the host
Those are acceptance criteria for the platform, tested rather than asserted.
Staff access
Balta staff accounts require multi-factor authentication without exception, and the staff console is IP-restricted and on a separate origin from anything a customer touches.
Staff access to a customer service is audit-logged, from the grant being issued to it being revoked, with the reason recorded. You see that in your own audit log.
Why a resource you cannot see returns 404
A resource outside your scope answers not_found, not a permission error. A 403 would confirm that
the resource exists, which is information you are not entitled to. authz.capability_denied is
different: it means you can see the resource and your role lacks the capability, and the error names
which.
What you will see
Attempts outside the boundary fail at the database with PostgreSQL's own message, and they fail immediately rather than partially:
ERROR: permission denied to create database
ERROR: permission denied to create extension "file_fdw"
HINT: Must be superuser to create this extension.Troubleshooting
must be superuser to .... The operation needs a privilege that is not granted on a managed
service. Recent PostgreSQL versions often word this as permission denied, with a detail naming the
SUPERUSER attribute.
must have admin option on role. From PostgreSQL 16, a CREATEROLE role can administer only the
roles it created. Grant from the role that created the target.
ALTER SYSTEM is refused. Server-wide configuration is the platform's. See
parameters for what you can change and how.
A restore fails on ownership. Restore with --no-owner --no-privileges. See
compatibility notes.