Skip to content
←Security

// Security · 04

Least Privilege

Broad admin rightsleads toScoped roleleads toOnly what is needed

Grant each identity only the permissions its job needs, and no more.

How it fits together

Least Privilege structureOrders serviceidentity: orders-svcBilling serviceidentity: billing-svcOrders schemaorders_svc: read, writePayments schemabilling_svc: read onlyBlocked: DROP TABLE1 SELECT, INSERT2 SELECT only3 DROP TABLE4 no grant
uses / callsfails / error path· numbered steps replay in order
  • Orders service uses / calls Orders schema (1 SELECT, INSERT)
  • Billing service uses / calls Payments schema (2 SELECT only)
  • Orders service fails / error path Blocked: DROP TABLE (3 DROP TABLE)
  • Orders service fails / error path Payments schema (4 no grant)

Spot it

  • One shared database login for every service
  • Service account has owner rights in production
  • Admin rights stay on months after a fix

It costs

More roles and grants to design and review, and some friction for on-call access.

Go deeperThe full explanation and what to ask for · 1 min readExpand

Least privilege limits the damage from a stolen credential, a bug or a compromised dependency. Each identity (user, service, pipeline, database login) should reach only the resources and actions it uses. A service that only reads orders should not be able to drop tables or read the payments schema, even if a bug tried.

The usual failure is convenience: one shared database account, a service running as admin "until we work out the roles", or a pipeline with rights to everything. Prefer managed or workload identities over long-lived passwords, so there is no secret to leak. Give the database one login per service, and grant on schemas or specific objects, not on the whole server.

Elevation should be rare and temporary. Human admin rights are granted just in time, for a stated reason and a fixed window, and the grant is logged. Review grants on a schedule, because permissions only grow unless someone removes them. When NOT to over-engineer: a solo project with one process may spend more on roles than it saves, but it should still never run as the owner of its database.

Ask for it

  • scoped role
  • managed identity
  • per-service database user
  • just-in-time elevation
  • separation of duties
  • blast radius

Replace the shared app login with one per service: orders_svc gets SELECT, INSERT and UPDATE on the Orders schema only, no DDL, no db_owner. Give the service a managed identity, not a password. Grant production admin through a one-hour role that needs approval and expires on its own.

Connects to