Access Control on DPG — Declarative PG

Roles

Mon, 01 Jan 0001 00:00:00 +0000

Roles are cluster-level objects. Declare them in .dpg files inside the cluster objects directory (e.g. production/cluster/roles.dpg). See Project Structure.

A role declaration is PostgreSQL’s CREATE ROLE without the CREATE: attributes such as LOGIN, PASSWORD and CONNECTION LIMIT go before the { } block, exactly where PostgreSQL puts them. The block holds only what CREATE ROLE can’t say: a comment, session settings, membership options, and renames.

ROLE app_readonly NOLOGIN {
 COMMENT 'Read-only access for reporting tools';
}

-- emits
CREATE ROLE "app_readonly" NOLOGIN;
COMMENT ON ROLE "app_readonly" IS 'Read-only access for reporting tools';

ROLE app_service
 LOGIN
 PASSWORD '{{env:APP_SERVICE_PW}}'
 CONNECTION LIMIT 20
 VALID UNTIL '2030-01-01' {
 SET statement_timeout = '30s';
}

-- emits
CREATE ROLE "app_service" LOGIN CONNECTION LIMIT 20 PASSWORD '<resolved>' VALID UNTIL '2030-01-01';
ALTER ROLE "app_service" SET statement_timeout = '30s';

{{env:APP_SERVICE_PW}} is a secret placeholder. It is resolved immediately before the statement runs, never during plan, so plans and snapshots never contain the password itself. Other backends use the same form, e.g. '{{vault:secret/roles/app_service#pw}}'. A password with no placeholder is rejected by the linter (rule hardcoded-role-password, see Linting).

Grants

Mon, 01 Jan 0001 00:00:00 +0000

DPG follows an additive grants model identical to raw PostgreSQL: declaring a grant emits GRANT. Removing a GRANTS entry from source emits nothing. To revoke, add an explicit REVOKES { } entry.

Table grants

TABLE orders ( ... )
{
 GRANTS {
 SELECT TO app_readonly;
 SELECT, INSERT, UPDATE TO app_service;
 ALL PRIVILEGES TO app_admin;
 }
}

-- emits
GRANT SELECT ON TABLE "public"."orders" TO "app_readonly";
GRANT SELECT, INSERT, UPDATE ON TABLE "public"."orders" TO "app_service";
GRANT ALL PRIVILEGES ON TABLE "public"."orders" TO "app_admin";

Revocations

TABLE orders ( ... )
{
 REVOKES {
 ALL PRIVILEGES FROM PUBLIC;
 }
}

-- emits
REVOKE ALL PRIVILEGES ON TABLE "public"."orders" FROM PUBLIC;

Column-level grants

Declared inside a COLUMN name { } block. The column scope is inferred.

Default Privileges

Mon, 01 Jan 0001 00:00:00 +0000

Default privileges apply to objects created in the future by a specific role. They are declared inside a SCHEMA { } block.

Default privileges for tables and functions

SCHEMA public {
 DEFAULT PRIVILEGES FOR ROLE app_admin {
 GRANTS {
 SELECT ON TABLES TO app_readonly;
 EXECUTE ON FUNCTIONS TO app_service;
 USAGE ON SEQUENCES TO app_service;
 }
 }
}

-- emits
ALTER DEFAULT PRIVILEGES FOR ROLE "app_admin" IN SCHEMA "public"
 GRANT SELECT ON TABLES TO "app_readonly";

ALTER DEFAULT PRIVILEGES FOR ROLE "app_admin" IN SCHEMA "public"
 GRANT EXECUTE ON FUNCTIONS TO "app_service";

ALTER DEFAULT PRIVILEGES FOR ROLE "app_admin" IN SCHEMA "public"
 GRANT USAGE ON SEQUENCES TO "app_service";

Supported object types in `ON` clause

Keyword	Applies to
`TABLES`	`SELECT`, `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, `REFERENCES`, `TRIGGER`
`SEQUENCES`	`USAGE`, `SELECT`, `UPDATE`
`FUNCTIONS`	`EXECUTE`
`TYPES`	`USAGE`
`SCHEMAS`	`USAGE`, `CREATE`

Revoking default privileges

SCHEMA public {
 DEFAULT PRIVILEGES FOR ROLE app_admin {
 REVOKES {
 EXECUTE ON FUNCTIONS FROM PUBLIC;
 }
 }
}

-- emits
ALTER DEFAULT PRIVILEGES FOR ROLE "app_admin" IN SCHEMA "public"
 REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Access Control on DPG — Declarative PG

Roles

Read-only role (no login)

Login role with password

Grants

Table grants

Revocations

Column-level grants

Default Privileges

Default privileges for tables and functions

Supported object types in ON clause

Revoking default privileges

Supported object types in `ON` clause