Least privilege for services and their credentials

Goal

Limit what an attacker can do after compromising one component to what that component could do anyway.

Prerequisites

A list of components and, for each, the resources it needs at run time.

Steps

1. Database: create a role per service with only the required privileges on the required schema; no superuser, no DDL at run time, migrations run with a separate role or step.
2. Container: run as a non-root USER, drop all capabilities, use a read-only root filesystem with a small writable tmpfs, set memory and PID limits, and do not mount the Docker socket.
3. Network: attach the service only to the networks it needs; put the database on an internal network without a host port.
4. Secrets: one secret per service and environment, injected at run time, rotated on schedule.
5. Files: mount configuration read-only; write only to explicitly designated volumes.
6. Review the permissions when the service changes; privileges tend to accumulate.

Expected result

A compromised web process cannot alter the schema, escalate on the host, or reach unrelated services; blast radius is one component.

Limits and test basis

Least privilege does not stop misuse of the permissions a service legitimately has (for example, reading its own data); application-level authorisation covers that. The settings follow the cited documentation and this wiki's own deployment.