Least privilege
by design.
A practical framework for reducing unnecessary permissions across AWS users, roles and workloads.
Least privilege is a lifecycle. Define the required task, grant the smallest useful permission, observe actual usage and continuously remove unnecessary access.
1. Start with the Workload
Permissions should follow the workload's actual actions. Avoid beginning with broad administrator access and trying to remove permissions later.
2. Prefer Roles
Use role-based access for workloads and temporary administrative access where practical. Keep long-lived credentials out of application code and automation wherever possible.
Workload identity → Assume role → Temporary credentials → AWS API3. Scope Resources
Where the service supports it, constrain actions to specific resources rather than using wildcard resources. Conditions can add useful context to an authorization decision.
What?
Grant only the API actions required for the task.
Which?
Prefer specific resource ARNs over broad wildcards.
When?
Use supported contextual constraints to narrow authorization.
4. Review Trust Policies
Permissions determine what an identity can do; trust policies determine who or what can assume a role. Review both sides of the relationship.
Principal → Trust policy → Role assumption → Permissions policy → Resource action5. Separate Human and Workload Access
Administrative access and application access have different threat models. Avoid reusing broad human administrator permissions for application workloads.
6. Use Conditions Carefully
Conditions can constrain access by supported context such as source, identity attributes or request characteristics. They should be tested against real operational flows before enforcement.
7. Observe and Iterate
Use access activity and operational evidence to identify permissions that are no longer required. Least privilege is a lifecycle, not a one-time configuration.
8. Troubleshoot Access Denied
When a request fails, identify the principal, action, resource and relevant policy evaluation context before changing permissions.
Request → Principal → Action → Resource → Identity policy → Resource policy → Conditions → Decision9. Common IAM Mistakes
- Wildcard actions. Broad permissions make effective access difficult to reason about.
- Wildcard resources. Resource scope is lost when every resource is allowed.
- Ignoring trust policies. A tightly scoped permission policy can still be reachable by an unintended principal.
- Long-lived access keys. Persistent credentials increase exposure and rotation burden.
- No review cycle. Permissions accumulate as workloads change.
10. Security Rule
Grant the minimum access required for a defined task, then continuously validate that assumption.