Identity security & governance for PostgreSQL
IGA tools stop at the identity provider and miss how role inheritance, SUPERUSER grants, and impersonation paths accumulate inside PostgreSQL. Oleria maps every login role, role inheritance chain, and pgaudit activity into a continuous identity security graph.
.png){kind=small}
Key Takeaways
- PostgreSQL uses one role system for users, groups, and admins, and IGA tools that stop at the identity provider miss how role inheritance, SUPERUSER grants, and row-level security bypass accumulate inside the database where sensitive data actually lives.
- Roles granted to other roles create inheritance chains that make effective privilege invisible without traversal, and SUPERUSER accounts can bypass row-level security and audit logging entirely, eliminating the controls compliance programs depend on.
- Oleria maps PostgreSQL login roles, role inheritance paths, impersonation chains, and pgaudit activity into a continuous identity security graph, making effective privilege visible at the individual user level rather than at the role assignment level alone.
- Continuous PostgreSQL access certification through Oleria flags dormant superuser accounts, unnecessary role memberships, and privilege escalation paths before they surface as audit findings or breach vectors.
This summary was created with AI and reviewed by an editor.
Ask AI to write a summary
Featured event: A CISO’s take
Join Jim Alkove and Ramy Houssaini to learn how forward-thinking security teams are addressing Enterprise AI Copilot risks.
Audit superuser accounts, untangle role hierarchies, and track row-level security bypass
Oleria's PostgreSQL integration gives security teams one view of who can access PostgreSQL data, how they got that access, and whether they use it. It brings PostgreSQL identity governance inside the database, where roles decide real access.
Oleria works across self-hosted and cloud-managed PostgreSQL. It maps login roles, role inheritance and impersonation paths into a continuous, real-time identity security graph, with pgaudit activity on top.
Why is PostgreSQL access so hard to govern?
In PostgreSQL, one role system covers users, groups and admins. Identity governance and administration (IGA) tools check accounts at the identity provider (IdP), so they miss what roles can do inside the database.
- Superusers skip every check. PostgreSQL superusers bypass all object-level permissions, so their reach never shows in a grant list.
- Nested roles hide true access. Roles granted to other roles stack up, which makes effective access to schemas and tables hard to calculate.
- Roles can become other roles. SET ROLE rights and SECURITY DEFINER functions let one role act as another, creating hidden escalation paths.
- Future tables inherit access. ALTER DEFAULT PRIVILEGES quietly grants access to newly created tables and schemas without review.
What Oleria shows you in PostgreSQL
How security teams use Oleria with PostgreSQL
- Audit admin rights. Identify accounts with superuser status, CREATEROLE rights or row-level security bypass.
- Unroll impersonation paths. Map indirect access created by SET ROLE and SECURITY DEFINER functions to remove hidden escalation routes.
- Govern future objects. Inspect default privilege settings so new tables do not inherit unintended public or group access.
- Right-size with real usage. Compare table and schema grants against pgaudit logs to find permissions unused for 30, 60 or 90 days.
How does Oleria connect to PostgreSQL?
Oleria connects in minutes with a dedicated PostgreSQL role that has CONNECT privileges on the databases you choose. Superuser status is not required for discovery. Optional pgaudit ingestion adds activity data. Read the Oleria PostgreSQL integration guide for setup steps.
PostgreSQL identity governance FAQs
What is PostgreSQL identity governance?
PostgreSQL identity governance is the practice of discovering which roles can access PostgreSQL data, through which grants, memberships and impersonation paths, and whether that access is used. Oleria delivers PostgreSQL identity governance by mapping login roles, object grants and pgaudit activity into one continuous identity security graph.
Does Oleria need superuser privileges to connect to PostgreSQL?
No. Oleria does not need PostgreSQL superuser privileges for discovery. Oleria only requires a dedicated PostgreSQL role with standard CONNECT privileges on the databases you want to inspect. Adding pgaudit logs is optional and lets Oleria stream DDL changes, role changes and connection events.
How does Oleria handle PostgreSQL superusers?
Oleria models PostgreSQL superusers as having full access to every database and object. PostgreSQL superusers bypass all object-level grant checks, so a plain grant list would look misleadingly empty. Oleria shows the true reach of each superuser account instead, which makes admin risk visible.
Can Oleria detect SET ROLE impersonation in PostgreSQL?
Yes. Oleria maps PostgreSQL SET ROLE assumption paths, superuser implicit role assumption and SECURITY DEFINER function execution chains. Together, these paths reveal the true effective access of every PostgreSQL identity, including privilege escalation routes that a simple grant review would miss.
Which PostgreSQL deployments does Oleria support?
Oleria supports self-hosted PostgreSQL and Amazon Web Services (AWS) RDS and Aurora. Oleria also supports Google Cloud SQL and Azure Database for PostgreSQL Flexible Server. Security teams can govern PostgreSQL access across all of these deployments in one Oleria identity security graph.
See who can really reach your PostgreSQL data, and cut the access nobody uses. Book a demo.
