Apply least privilege

Every permission increases what a mistake or compromise can damage. Least privilege means you start with no access, then add the narrow capability the task needs.

The principle sounds easy until you look at real credentials. A reporting job may read invoices but should not delete them. A deployment token may publish one project but should not administer the account. Most systems drift the other way, because broad access is granted once and never reviewed.

Why the scope of a token matters

A nightly reporting job needs to read invoice totals. Someone creates it with the team’s admin credential because that already works. Months later the credential appears in a CI log — logs leak constantly, through verbose error dumps or debug flags left on.

Now compare outcomes. With a read-only credential, the leak exposes invoice data. Bad, but bounded. With the admin credential, one leaked CI log turns a reporting failure into data loss, because whoever reads the log can delete every invoice.

The database version of this is two statements:

CREATE ROLE reporting LOGIN PASSWORD 'use-a-generated-value';
GRANT SELECT ON invoices TO reporting;

No DELETE, no UPDATE, no access to other tables. The blast radius of a compromise is now the same as the blast radius of the job itself.

Verify the denial, not just the success

A privilege model you never tested is a guess. Run one normal reporting task with the read-only credential and capture the successful result. Then attempt a delete with the same credential:

DELETE FROM invoices WHERE id = 4211;
-- ERROR: permission denied for table invoices

Keep that denied response as evidence. The error is the point: it proves the boundary exists in the running system, not just in a design document.

The convenience objection

Narrow access can make operations less convenient. One day someone genuinely needs to fix bad invoice rows, and the read-only role blocks them. The wrong answer is widening the routine credential “temporarily” — temporary grants become permanent because nothing forces their removal.

Keep a separate, audited recovery path instead: a break-glass role that requires a second person or writes a log entry every time it is used. And review privileges when roles, services, and projects change, because yesterday’s necessary access is today’s unnecessary risk.