Beginner 15 min read

The Principle of Least Privilege

By the end of this lesson, you'll be able to:

Explain the principle of least privilege in one sentence
Identify over-permissioned access in a realistic scenario and explain what is wrong with it
Design a narrowly-scoped permission set for a specific, described task

Prerequisites: "IAM Roles and Policies"

The principle, stated plainly

Least privilege: grant only the permissions a task actually needs, and nothing more.

It sounds obvious once stated, but the tempting alternative shows up constantly in real teams: "just give the developer AdministratorAccess, it's easier than figuring out exactly what they need." That single sentence is the principle of least privilege being abandoned for convenience — and it's worth understanding exactly what it costs.

A worked scenario

Consider a reporting process whose entire job is to read objects from one specific S3 bucket every night and generate a summary.

That process needs exactly one thing: read access to that one bucket. Under least privilege, it should not also receive:

Write or delete access to that bucket, or any other bucket — it never writes or deletes anything.
EC2 permissions — it doesn't touch servers.
IAM administration permissions — it certainly doesn't need to create or modify other identities.

Every one of those extra permissions would do nothing to help the reporting process do its actual job. What they would do is widen the damage possible if that process's credentials were ever compromised — an attacker who compromises a read-only identity can only read; an attacker who compromises an over-permissioned identity inherits everything it was needlessly given.

Side-by-side comparison showing a reporting workload given broad AdministratorAccess labeled as a huge blast radius if compromised, versus the same workload given a narrow s3:GetObject policy on one bucket labeled as exactly what the task needs. — Broad access is never the safe default — it's a cost paid for convenience, not a normal starting point.

Why "easier" is a false economy

Granting broad access up front feels faster in the moment — no need to figure out the exact list of actions a task requires. But that convenience is borrowed against future risk: every identity with more access than it needs is a larger target, and a larger potential loss, for exactly zero ongoing benefit. Figuring out the narrow, correct permission set once, up front, is cheaper than the alternative in every case that actually matters.

This is also why the previous lesson's dangerous "Action: , Resource: " example is worth remembering here specifically — it's the least-privilege violation taken to its logical extreme.

Exercise

A nightly reporting process only needs to read objects from one specific S3 bucket. List every permission it should NOT receive under least privilege, and explain briefly why each one would violate the principle even if it "might be useful someday."

Show hint

Consider write access, delete access, permissions for entirely different services, and IAM administration permissions.

The Principle of Least Privilege Quiz

1. A reporting process only ever reads from one S3 bucket. Which permission set best follows the principle of least privilege?

Read-only access limited to that one specific bucket Full read/write/delete access to all S3 buckets in the account AdministratorAccess, so it never runs into a permissions error Read access to that bucket plus EC2 access, in case it needs a server later

2. Granting an identity broad permissions "to save time" has no real downside as long as that identity is never actually misused.

True False

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

The principle of least privilege means granting an identity only the specific permissions its task actually requires — nothing broader "to be safe" or "to save time" — because every unnecessary permission is a risk that provides no corresponding benefit.

❬ Previous Next ❭