Have you replaced IAM Users with AWS SSO yet?
The most secure option to isolate workloads from each other is to use multiple AWS accounts. Many organizations use different AWS accounts for testing and production, for example. The more AWS accounts you use, the more complicated it gets to manage users and grant them access.
Formerly, using IAM roles for cross-account access was a popular pattern. How did that work in practice? Often, everything started with an AWS account that contained nothing but the IAM users and groups, allowing engineers to authenticate. Besides that, account administrators added IAM roles for cross-account access to every AWS account.
When an engineer wanted to access AWS account B
, she needed to authenticate with her IAM user at AWS account A
first. In a second step, she could assume the IAM role in AWS account B
. Using temporary security credentials, she could act under the IAM role to access or modify resources in AWS account B
.
That’s a cumbersome approach because you need to deploy and manage many policies and roles across your AWS accounts. Also, the user experience for anyone who wants to access resources in an AWS account was far away from being simple.
AWS introduced AWS Single Sign-On (SSO) in December 2017. In the beginning, an Active Directory was a requirement to be able to use the service. But AWS SSO made astonishing progress within the last few years. Nowadays, AWS SSO is an excellent alternative to using IAM users and groups for managing access to AWS accounts for your engineers.
AWS provides three options to manage users and groups:
- Built-in user store.
- SAML to integrate with 3rd party identity providers (e.g., Google).
- Connect with Active Directory (requires AWS Directory Service).
The first two options are very lightweight and work well for SMBs. Next, I’ll demonstrate why you should replace your IAM users with AWS SSO next.
Minify Overhead: AWS Organizations
Managing tens or hundreds of AWS accounts is a challenge. AWS Organizations simplifies governing AWS accounts not only for big enterprise customers. You can think of AWS Organizations as a layer on top of AWS accounts.
There are some pitfalls when introducing AWS Organizations as well. I’ve summarized my thoughts on that in a former blog post: AWS Account Structure: Think twice before using AWS Organizations .
AWS SSO integrates with AWS Organizations. By doing so, AWS SSO provisions IAM roles and identity providers within all your AWS accounts with the click of a button. No need to roll out IAM roles manually anymore.
That’s a significant benefit compared to managing IAM users and roles yourself.
Improve User Experience: Login Portal
On top of that, AWS SSO comes with a login portal. First of all, the user needs to authenticate. Afterward, the login portal shows a list of all AWS accounts and permission sets (aka. roles) that the user has access to.
From there, a user jumps into one of the AWS accounts directly. It gets even better. The AWS CLI works with AWS SSO as well.
Want to learn more about AWS SSO? Andreas shows how to use AWS SSO for SMBs in the following video.
Summary
Are you using IAM users to authenticate and jump into other AWS accounts by using IAM roles? Give AWS SSO a try. It is easy to manage for administrators and easy to use for engineers. The best comes last: AWS SSO is free of charge.
Further reading
- Article AWS Account Structure: Think twice before using AWS Organizations
- Article Terraform, can you keep a secret?
- Article How to avoid S3 data leaks?
- Tag security
- Tag iam
- Tag highlight