Least privilege for database service accounts

WHAT THIS TESTS Whether you instinctively scope permissions to the minimum and understand why an over-privileged service account dramatically widens the impact of any breach or bug.

WHY IT MATTERS The principle of least privilege states that every account should hold only the permissions strictly necessary to perform its function. If that account is compromised through SQL injection, a leaked credential, or a code bug, the attacker inherits exactly its rights, so narrow rights mean a contained incident.

A GOOD ANSWER COVERS For a new application service account, never reuse the database superuser or owner. Create a dedicated role for the application, then grant only the data verbs it actually performs, such as SELECT, INSERT, UPDATE, and DELETE, and only on the specific tables and schemas it touches. Withhold schema-altering DDL rights like DROP and ALTER, withhold the ability to create users or grant privileges, and avoid blanket ALL PRIVILEGES. Where the workload allows, split responsibilities: a read-only account for reporting, a separate migration account that holds DDL rights but is used only during deploys. Store the credential in a secrets manager, not in source code.

COMMON WRONG ANSWERS Granting admin or ALL PRIVILEGES for convenience, sharing one account across multiple services, or embedding the password in the repository.

LIKELY FOLLOW-UPS How row-level security narrows access further; how to rotate credentials; why DDL belongs to a migration account, not the running app.

ONE CONCRETE EXAMPLE A new orders service gets a role granted SELECT, INSERT, and UPDATE on the orders and order_items tables only. It cannot read the users credentials table, cannot drop tables, and cannot create accounts. If an injection flaw is later found, the attacker is confined to order data rather than owning the entire database.