Your One New Years Resolution in AWS should be...

Posted by Ben Potter on Thursday, December 31, 2020

The one thing you should do as your new years resolution if you’re using AWS is….

STOP USING IDENTITY & ACCESS MANAGEMENT USERS!!!

OK, that might sound harsh and be a bit difficult to do immediately, but you should definitely stop using them in production environments, and have a plan to stop using them this year.

What’s Wrong With IAM Users?

IAM users used to be the recommended way to login to the console and access the API’s, as they are much more secure than the root user (they cannot close your account, and can have permission policies). IAM users are specific to a single AWS account, which means if you have more than one AWS account, you need to use IAM roles in the other accounts unless you want to duplicate IAM users which is near impossible to manage. IAM users and the root user can also have access keys assigned, these access keys cannot have multi-factor authentication (MFA) enforced and the permissions the access key has is the same as the user. IAM and root user dangerous as you could leave this laying around or accidentally commit it to GitHub. This access key can be rotated, however it’s easy to forget.

What You Can Use Instead

Services and features have improved over the years, and as of July 2020 AWS Well-Architected which curates recommendations and best practices added a best practices to Rely on a centralized identity provider. If you have one or more AWS accounts, you can use AWS Single Sign-On (SSO) that allows you to configure users, including yourself, in the service. The users can have permissions following least-privilege, and the best feature I believe is they can be used across all your AWS accounts in your AWS Organization. SSO provides you access to the AWS console, and can even generate you temporary credentials including an access key which you can use in the AWS CLI. AWS SSO also helps you manage access and permissions to commonly used third-party software as a service (SaaS) applications, AWS SSO-integrated applications as well as custom applications that support Security Assertion Markup Language (SAML) 2.0. The best part of SSO is there is no cost! I use SSO even for a couple of my personal testing accounts so I’d encourage you to do the same. If you already have a central identity/directory service, it most likely supports SAML 2.0 or Open ID Connect (OIDC). If SSO is not for you, then you can enable federation with IAM.

Further Reading

AWS Well-Architected
Managing user permissions at scale with AWS SSO