Least Privilege and Role-Based Access

Tiffin's pipeline runs every job as one cloud identity with full admin rights, because that was the quickest way to make deploys work. One day a compromised test dependency runs code inside the test job. With admin rights, that code could delete the production database. With the right permissions, it could have done almost nothing.

The rule

Grant only what the task needs, only to whoever does it, only for as long as needed.

Identity and access management (IAM) is the system that decides who (or what) can do which actions on which resources. Least privilege is the rule for filling it in: start from nothing and add only the permissions a task actually requires.

The point is blast radius. You will never prevent every compromise, so make sure a stolen credential opens as few doors as possible.

Role-based access control (RBAC) makes this manageable. You define roles around jobs, give permissions to the roles, and assign people or services to roles:

Now a new teammate gets the developer role in one step, and removing it removes everything at once.

Least privilege applies to three kinds of identity:

• People: no standing production admin. Use a time-limited, approved and logged elevation for emergencies.
• Services: the Tiffin app's database user can read and write its own tables, not drop them.
• Pipeline jobs: one role per job, scoped to one environment. The job that runs untrusted pull-request code gets no secrets at all.

Permissions drift upward over time. Compare what each role is granted with what the logs show it uses, and remove the difference.

The shortcut

For any identity, write its job in one sentence, then grant only the verbs and resources in that sentence.

Drills

Answer fast — trust the rule.

Remember

• Grant only what the task needs, only to whoever does it, only for as long as needed.
• Write the identity's job in one sentence; grant only its verbs and resources.
• People, services and pipeline jobs all need least privilege; prune unused rights.