This content originally appeared on DEV Community and was authored by SHAJAM
Introduction
IAM Users and Roles in the context of Zero Trust Security Framework. The article discusses the principle – Never trust, always verify, and minimize exposure and how IAM users and roles plays with it.
The IAM users, roles, and policies section is where you establish how identity becomes the new perimeter in AWS. This is the core service that defines permissions for users and services and what they can do. For example, if you want a Lambda function to read and write data from a S3 bucket, you have to configure permissions. You configure it using IAM.
IAM User
IAM User are long-term identities created for people (e.g., developers, administrators) needing direct access to AWS resources. When you create the user, you can give it console login permission so the user can login to your AWS account. To make it secure, you can and should enforce MFA on the IAM user account console login.
You might also use IAM user to obtain the access keys. Access keys are long term tokens that you can use with your application or external applications or users. These tokens are long-term and therefore if leaked can be used for malicious activities.
Best practice using IAM User and Access Keys
- As an alternative to access AWS console using IAM user, consider federated access via IAM Identity Centre (AWS SSO) or external IdPs. That way, user login is tied to federated access you don’t need to manage the IAM user.
- Never share IAM user credentials.
- Enforce MFA (Multi-Factor Authentication) for all IAM users.
- Rotate access keys regularly or use short-lived credentials (STS).
Zero Trust Tie-In: Long-lived credentials represent implicit trust — contrary to Zero Trust. Migrating to temporary credentials aligns with Zero Trust principles.
IAM Roles
IAM Roles are identities with permissions that can be assumed *temporarily * by trusted entities (users, applications, services, or other AWS accounts). For example, if you have an EC2 instance that needs to read or write data from S3, you can create an IAM role and associate it with the EC2 instance. Then, it can perform S3 operations.
You might wonder how is it different from access keys then. Well, the main difference is that the IAM role is providing temporary tokens issued via AWS STS – Security Token Service that is used for authorisation. With access keys, the keys are long term. Another difference is, with access keys, anyone or service can use the it to gain access to AWS. That is, you can use the access keys from your laptop, from EC2 or Lambda and you can still access the resource. Whereas, with IAM role, you define an IAM trust policy that defines what can assume the role. If the trust policy specifies EC2, then only EC2s can assume the role and using the same role with Lambda will fail.
Use Cases:
- Service Roles: EC2 instance needs to read from S3.
- Cross-Account Access: Account A allows Account B to assume a role to access its resources.
- Federated Access: Users from an external IdP assume roles dynamically when signing in.
Thus, IAM roles provide a Zero-Trust benefit – temporary credentials and dynamic trust relationships reduce attack surface and eliminate static trust assumptions.
Summary
IAM users violate this principle because these rely on long-term credentials (passwords, keys) and does not really have trust relationships.
IAM roles support Zero Trust because
- Access is dynamic and time-bound.
- Role assumption requires continuous authentication (STS token issuance).
- Least privilege can be enforced with fine-grained policies and session conditions.
This content originally appeared on DEV Community and was authored by SHAJAM