IAM Principals, Policies, and Least Privilege

What least privilege actually asks for

"Least privilege" is often repeated as an attitude. It is really a specification with three dimensions.

Least privilege grants only the actions required for a task on specific resources under specific conditions.

A policy that leaves any of the three wide open is not least privilege, no matter how carefully the remaining one is written. Granting broad actions on every resource and promising to watch the logs afterwards is the classic version of this: monitoring reports what happened; it does not narrow what is possible.

Two other misreadings are worth naming. Granting every action the account has ever recorded ignores the task boundary entirely. And an organization-level permissions ceiling grants nothing at all — it caps what an identity may do, so it can never be the thing that gives access.

Narrowing a policy from observed activity

Writing a tight policy from scratch is hard, which is why observed behavior is such a useful input. IAM Access Analyzer can generate a fine-grained policy from services and actions recorded in access activity.

Suppose activity shows that a production role used three actions against a single resource while its attached policy grants many services. The path is to generate the fine-grained policy from that recorded activity, test it, and then deploy the narrowed version. Generation supplies the draft; testing is what protects the task that must keep working.

The alternatives make things worse in different ways: attaching another broad policy for redundancy widens exposure instead of reducing it, stripping every permission on the assumption that a ceiling will supply access misunderstands what a ceiling does, and granting the three actions on every resource narrows only one of the three dimensions.

People federate, workloads assume roles

Before choosing any object, decide who is asking: a person or a workload. The recommended answer differs, but both land on temporary credentials.

Human users should use federation and temporary credentials rather than IAM users with long-term credentials.

An IAM role supplies temporary credentials to a trusted user, workload, application, or AWS service. That single sentence covers people, machines, and services alike.

For workloads the mechanism is especially clean. Applications on supported AWS compute services can obtain role credentials without distributing long-term IAM user credentials. Nothing has to be embedded in an image, a configuration file, or a repository.

Note what cannot fill this position: a group is a permission container and is never attached to a compute resource as an identity, and a policy on a resource does not manufacture credentials at start-up.

When an IAM user is the exception

The preference for roles is strong, not absolute. An IAM user is appropriate for a specific use case that requires long-term credentials and cannot use an IAM role. An IAM user has an individual set of security credentials.

The exception comes with upkeep. When an IAM user must have long-term programmatic credentials, access keys should be updated when needed and access-last-used information can support safe removal.

Take a legacy tool that cannot assume a role and needs an access key. The user is justified, and the maintenance follows: update the key when it needs updating, and use last-used information to decide when a key can be removed without breaking anything.

What does not follow from a supported exception:

• The key does not become an account root credential. Root is not a convenience upgrade.
• The key does not move into a group to be shared. An IAM user's credentials are individual, and groups hold permissions rather than secrets.
• The key is not left untouched forever. Long-term credentials can and should be updated.

The root user, and the control that belongs with it

The account root user is the one identity with no substitute and no fallback. AWS account root user credentials should be safeguarded like other sensitive personal information. The AWS account root user cannot switch to an IAM role, so the usual "drop into a narrower role" reflex is not available here.

When an exceptional identity has to be used, the answer is an added sign-in control rather than a redesign of the identity. MFA requires both a user's credentials and a device-generated response to complete sign-in. MFA is recommended when an IAM user or root user is required.

Evaluate the two halves separately: the scenario tells you which identity is unavoidable, and MFA is what strengthens the sign-in for it. A group membership grants nothing to root, and naming a group in a policy on a resource is invalid for reasons covered later.

Groups manage permissions; they are not identities

A group is the answer to "several people need the same permissions", and nothing else. An IAM user group is a collection of IAM users that receives permissions from identity-based policies attached to the group.

Attach the policy once, add users to the group, and the assignment scales without repeating itself per person.

Two limits define the shape of the object. IAM user groups cannot be nested and cannot be named as a Principal in a resource-based policy.

That second column is where scenario questions live. Separate the permission-management container from an authenticated identity and from an assumed session before choosing among these objects, and the wrong answers stop being tempting.

Two places a policy can live

Permissions are expressed in policies, and where a policy is attached changes what it can say. Identity-based policies grant permissions to IAM users, groups, and roles, while resource-based policies are attached to resources.

Within identity-based policies there is a second choice, about how tailored the permission set is. AWS managed policies can provide a starting point, but customer managed policies can be reduced for a specific use case.

A managed policy is a reasonable way to get a workload running. Once the use case is mature and its real needs are known, the narrowing move is a customer managed policy scoped to that use case. A broad managed policy does not become least privilege by having been used for a long time, and moving a workload into a group while detaching its policies removes the permissions rather than tailoring them.

Granting access from the resource side

Sometimes the resource itself should do the granting. A resource-based policy can grant access by naming an authenticated principal, but an IAM user group cannot be that Principal.

There is also a boundary on how far that delegation reaches: IAM roles and resource-based policies can delegate cross-account access only within one AWS partition.

So a direct-resource-access design is checked in three steps, in this order:

1. Attachment point — is the policy on the resource, where it can name a principal?
2. Named object — is the named object an authenticated principal, and not a group?
3. Partition — are both accounts inside one AWS partition?

Run a valid case through it. A service resource must grant access directly to an authenticated identity in another account within the same partition: attach a resource-based policy to the resource and name the permitted principal. All three checks pass.

Now the invalid one. A bucket policy names an IAM user group in another partition, and the design insists on keeping the group as the named identity. It fails twice over, on two independent boundaries: a group is not an authenticated principal, and delegation through roles or resource policies does not cross partitions. Neither failure rescues the other, and no policy converts a group into a role on arrival.

Choosing the object for the need

With the pieces separated, selection becomes mechanical. Choose a user for a supported long-term-credential exception, a group to manage permissions for multiple users, a role for temporary credentials, and a policy to express permissions.

Mixed requirements are just two selections made independently. A build service that must not carry a long-term key needs temporary credentials, which is a role. Five operators who need one permission set managed together need a group with an identity-based policy attached. Choosing the principal first, then comparing the required permission scope with the policy choices, keeps the two halves from contaminating each other.

Key takeaways

• Least privilege is specific: only the required actions, on specific resources, under specific conditions.
• Let observed activity draft the policy: Access Analyzer can generate a fine-grained policy from recorded services and actions, and the result is tested before it replaces production access.
• Prefer temporary credentials: people federate, workloads assume roles, and applications on supported compute services obtain role credentials without long-term keys being distributed.
• Treat the IAM user as an exception: it fits a use case that needs long-term credentials and cannot use a role, with keys updated when needed and last-used information guiding removal.
• Protect root and add MFA: root credentials are safeguarded like sensitive personal information, root cannot switch to a role, and MFA adds a device-generated response when root or an IAM user is required.
• Know each object's job: a group manages permissions for multiple users but is neither an authenticated principal nor nestable; identity-based policies attach to identities and resource-based policies attach to resources; delegation stays inside one AWS partition.