Elevarq Signals 1.3.0: Know Who Can Access What

Elevarq Signals 1.3.0 adds object and default privilege collection, making PostgreSQL grants — including access through PUBLIC — explicit, normalized, and ready for analysis.

Frank Heikens··2 min read

Over-broad grants are one of the most common and least-noticed PostgreSQL misconfigurations. A table left readable by PUBLIC, a GRANT on the public schema that survived a migration, a default-privilege rule that hands every future object to a broad role — none of it shows up in a role list, and none of it raises an error. It just quietly widens your attack surface.

Signals already collected the context around this — login roles, role capabilities, row-level security policies — but not the grants themselves. 1.3.0 closes that blind spot, and it's available now on AWS Marketplace and GHCR.

Object and default privileges, normalized

1.3.0 adds two read-only collectors:

  • Object privileges — the actual access-control lists on tables, views, materialized views, sequences, and foreign tables (relacl), on schemas (nspacl), and on functions (proacl).
  • Default privileges — the ALTER DEFAULT PRIVILEGES state (pg_default_acl): what future objects will inherit before they even exist.

Both normalize PostgreSQL's aclitem[] arrays with aclexplode() into one row per grant — object, grantee, privilege, and whether it can be re-granted — and render the PUBLIC pseudo-role explicitly, so "granted to PUBLIC" is unambiguous instead of an empty grantee you have to know to interpret.

That turns a pile of catalog internals into a flat, queryable grant list your analysis layer can act on: a table exposed to PUBLIC, broad privileges on the public schema, or a default-privilege rule that will keep re-granting to PUBLIC on every new object someone creates.

It reads only privilege metadata — never object data — and needs nothing beyond the least-privilege pg_monitor role Signals already runs as. No new grants, no elevated access.

Also in 1.3.0

  • One snapshot file per database. The scheduled file export now writes a separate snapshot archive per database instead of a single combined one, so a downstream reader sees each database distinctly — the difference between "one database" and your whole fleet when you collect more than one.
  • 102 collectors. The two new privilege collectors bring Signals to 102 read-only diagnostic collectors across activity, schema, security, replication, and more.
  • Dependency hardening. golang.org/x/mod is updated to clear two module-integrity advisories (GOPROXY/GOSUMDB tile forgery).

Every collector ships with a specification and tests, and the release passes our standard gates: reproducible CI/CD builds, SBOM generation, image signing, and vulnerability scanning.

Getting it

Elevarq Signals is free. 1.3.0 is on AWS Marketplace (Helm on Amazon EKS) and on GHCR for direct consumers, with a Helm chart for Kubernetes. It runs as a least-privilege pg_monitor role and collects strictly read-only — no writes to your database, ever.

If you run PostgreSQL and can't answer "who can actually read this table?" with confidence, this is the release to add.

Written by

Frank Heikens

Frank Heikens is the founder of Elevarq and a PostgreSQL engineer with 20+ years of experience in database performance and architecture. His work has focused on large-scale, performance-critical PostgreSQL systems where latency, throughput, and reliability matter. At Elevarq, he focuses on understanding why PostgreSQL systems behave the way they do—and turning that understanding into practical, evidence-based recommendations.

Reactions