Why you should not use IAM users

AWS provides you with two main options for giving users access to your AWS resources: IAM users and roles. But there is really only one option.

AWS describes two IAM entities that can be used to access their services: IAM users and IAM roles. The IAM FAQ seems to treat these as equally valid and useful concepts when designing your access control strategy.

Flowchart outlining the decision process.

At first sight, IAM users seem to be the more powerful concept. IAM users do not only support inline and managed policies but can also be organized in groups, ostensibly enabling more sophisticated permission management systems like role-based access control (RBAC; pun intended). However, in most contexts, IAM users should not even be considered. This story lists nine reasons why.

Disclaimer: There are certain situations where the simplicity of getting started with IAM users outweighs all of the points made below. This will primarily be the case in smaller AWS environments and in the absence of an existing identity store.

Nine reasons not to use IAM users

1) IAM users conflate authentication and authorization

Although authentication and authorization are often used interchangeably, they represent fundamentally different functions. Maintaining these functions as separate configuration items is usually a good idea.

IAM roles define a permission set, but do not pretend to correspond to an identity. They are clearly an authorization primitive. IAM users conflate identities with their permissions by incorporating both the authentication and authorization functions. I am aware that this is not a very tangible reason not to use IAM users — but it is foundational and at the basis of many of the reasons listed below.

2) IAM users are only suitable for workforce users

Identity control systems often distinguish between corporate or workforce users and customer, consumer or application users.

• Workforce users can be employees or trusted parties like contractors and partners. They are typically managed in solutions such as Microsoft Active Directory, Okta Workforce Identity or Google Cloud Identity.
• Customer users can be users of your website or app. They are typically managed in solutions like Auth0, Okta Customer Identity or Google Identity Platform.

IAM users cannot be used for customer users. One reason is the user experience: customer users will not create an AWS password and generate secret keys just to use your application. You can also only create up to 5000 IAM users per account.

3) IAM users are mostly unsuited for machine users

Not all IAM scenarios involve a user. In machine-to-machine authentication (M2M), there is no human identifying him- or herself to a service through a client. Instead, it is the client or “machine” identifying itself to a service.

Machine users running on AWS already have a machine identity that is known to a trusted party: AWS itself. They can easily be authorized through roles. On EC2 instances and many other services, this happens through the metadata service, but there are also mechanisms such as IAM Roles for Service Accounts (IRSA) for EKS and AWS-managed temporary credentials. Using these AWS-provided (machine) authentication mechanisms is always preferable to storing IAM user credentials (where would you store them anyway?). IAM users can be an option for M2M authentication of clients living outside of AWS.

4) IAM users cannot be federated

Whether your users are corporate users that exist in your enterprise’s Active Directory or customer users that log in through an OIDC identity provider, chances are that you can already authenticate them. Identity federation refers to the process of delegating the responsibility of authentication to a trusted external party.

Unfortunately, it is not possible to federate an IAM user. You cannot authenticate an IAM user from your existing identity provider. In contrast, AWS offers many ways of authorizing your external identity provider to grant permission to assume roles. Identity federation results in a better user experience, but also in increased security, as there are fewer identities and credentials to manage.

5) IAM users are not a good identity store

IAM users corresponding to identities might sound good to you if you do not already have an identity provider form which you can federate identities. Unfortunately, IAM users are not a good identity store for several reasons.

• IAM users are tied to a single account. Unlike an IAM user account, a user’s identity does not stop at the boundaries of a single AWS account. This will be more of a problem for you if you work in a cross-account context.
• You cannot federate IAM user identities. Say you create IAM accounts for all your corporate users. If you want these users to then authenticate themselves to a service that is not AWS, you have no way of using their existing IAM user identity for authentication.

One managed AWS solution that you can use that addresses these issues is AWS Single Sign-On, which can federate roles across different accounts in your organization and act as a (SAML) identity provider to external parties.

6) IAM users violate the principle of least privilege

A cardinal concept in the world of security is the Principle of Least Privilege (PoLP). This principle states that subjects should be given only those privileges needed for them to complete their tasks, but also that it should be the function of the subject, not its identity, controlling the assignment of rights.

One way of interpreting this second part is that even in situations where an individual can work in many functions or roles, they should ideally never wield the combined permissions required to perform all these functions at the same time. Remember that you generally delegate all the permissions you wield to any program you start! Similar to how we do not run all our Linux programs as the root user (or, in modern times, with all capabilities), we should scope our AWS credentials down before calling on applications interfacing with AWS. This is also of the main ideas behind Palantir’s concept of purpose-based access control.

Capturing function permissions in IAM groups and adding users to those groups would this concept and the PoLP. Role definitions, on the other hand, can correspond to permission sets mapping onto “subject functions”. You can then allow identities to assume those roles based on whether they should be able to perform a function. Note that you can still use IAM users — assign almost no permissions to the users, except permissions to assume roles.

7) IAM groups complicate things

AWS IAM is complex; wading through inline policies, managed policies, resource-based policies, permissions boundaries, service control policies and more in an attempt to figure out why access to a resource was granted or denied is a complex endeavour.

IAM users add the concept of IAM groups to the already hard-to-grasp IAM system. They may not complicate IAM further by much, but “not much” can be the proverbial drop in the bucket. Every user can be a member of up to ten IAM groups, to which you can also attach inline as well as managed policies. This added layer of complexity can make debugging your IAM decisions even more difficult. Remember that permissions in AWS are not always additive (an applicable deny statement always takes precedence over any allow) — so group membership does not necessarily mean that you can do more!

8) IAM roles are inescapable

AWS-native services and AWS machine users rely on roles to function properly. Roles are inescapable, which means you will have to familiarize yourself with roles and adapt to their limitations anyway. There is no such dependency on IAM users, so why familiarize yourself with their intricacies too?

• Depending on IAM groups to organize your permissions might be a bad idea, as there is no equivalent grouping concept for roles.
• Maximum inline policy lengths are different for IAM users, IAM groups and IAM roles.
• Roles can behave differently compared to IAM users in the presence of resource-based policies and permission boundaries, something that can surprise even seasoned IAM veterans like Ben Kehoe.
• Session policies and resource-based policies targeting role sessions behave differently than those targeting the parallel concept of federated IAM users.

9) IAM users promote the use of long-lived credentials

IAM users authenticate themselves to the administration console using usernames and passwords, and programmatically through API keys. Both types of credentials are long-lived.

For passwords, you can enforce MFA and expire passwords, e.g. periodically. The former is definitely a good idea. Whether the latter increases or decreases security has been a topic of hot debate in security circles for a long time. Not everyone will agree, but I am of the opinion that you should not enforce rotation, and I am not in bad company:

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. — NIST SP800–63B

For API keys, two keys can be active at the same time, enabling key rotation without downtime. AWS mentions regular key rotation as being “one of the key steps in protecting your resources from unauthorized access”. However, generating and rotating keys is usually a manual process for your users. You can ask them if they have to rotate their keys, but they will not like it and likely not do it. You can track your users using AWS Config and even enforce key rotation using automatic remediation, but I consider API keys to be similar to passwords and am not sure whether to consider such enforcement to be a good practice (although, at least, API keys are random and not memorized). If you can avoid this whole discussion by using roles instead, that’s a win!

That’s a wrap! Some of these reasons might not apply to you, and by themselves, not all of them are particularly strong. But all together, I find they make a compelling argument not to use IAM users at all. There can be exceptions; IAM users are an easy way to get started with AWS and sufficient in some non-enterprise cases. They can be a decent solution for machine authentication, and you may opt to use them for a select group of users such as your account administrators.

Alternatives to IAM users

If not using IAM users, then how to authenticate your users and authorize them by allowing them to assume roles? AWS, as they are wont to do, provides you with many options:

• Web identity federation (AssumeRoleWithWebIdentity)
• SAML identity federation (AssumeRoleWithSAML)
• Amazon Cognito Identity Pools (GetCredentialsForIdentity)
• AWS Single Sign-On (SSO)

A discussion of how and when to use these is not the topic of this post. If you are managing an AWS Organization and were looking at using AWS IAM users, chances are that you should be looking at AWS SSO instead.

If you want some expert advice on how to manage your AWS identities and permissions, consider contacting us!