A new grant_coverage check reports roles and users whose privileges reach a large share of the database, graded by the Atlas Security Graph with configurable warning and error thresholds.
The new grant_coverage lint check reports the privilege reach of database roles and users, showing the share of securable objects their grants let them read or write to. With atlas migrate lint, it grades every role and user the migration creates, alters, or grants privileges to, and with atlas schema lint it grades all of them, including unreachable roles that hold dead grants and objects granted to PUBLIC. The reach is computed by the Atlas Security Graph in Atlas Cloud, so the findings match what the Security tab shows for the schema.
Configuration
The check reads the schema's roles and grants, so the env must enable their inspection. Thresholds are the percentages of reachable, securable objects that trigger a report (default 50) and fail the command (default 75). Setting a threshold to 0 reports every role or user that holds a grant.
env "prod" {url = "postgres://..."dev = "postgres://..."schema {mode {roles = truepermissions = true}}lint {grant_coverage {warn_threshold = 50error_threshold = 75}}}
Behavior
- A write reach at or above error_threshold fails the command. An explicit error attribute overrides the thresholds in both directions.
- A read reach that broad is reported as well, but does not fail the command on its own.
- Findings that describe the schema rather than a change, such as unreachable roles holding grants or PUBLIC grants, are reported by atlas schema lint.
- The check requires a connection to Atlas Cloud and is skipped when it is unavailable or does not respond within timeout.
Example
A migration that creates a role and grants it every privilege on all tables fails the lint run once the role's write reach crosses the error threshold:
$ atlas migrate lint --env prod --latest 1Analyzing changes from version 1 to 2 (1 migration in total):-- analyzing version 2-- grant coverage issues detected:-- L2: Role "gc_app" has write access to nearly all securable objects (4/5 (80%)): broadenough that a single compromise could alter or destroy most of the database. Applyleast privilege to role "gc_app": replace broad grants with grants on the specificobjects it needs, or split it into narrower purpose-specific roles-- ok (832.973µs)--------------------------- 281.840981ms-- 1 version with errors-- 5 schema changes-- 1 diagnostic