Use SSO instead of IAM users to connect to your AWS accounts

I’ve noticed that some folks think AWS SSO (and the related AWS Organizations) is only for big companies and isn’t relevant to them, or is too much overhead to setup. I disagree with this stance and want to explain why I think small companies should be using SSO to allow access to their AWS accounts.

I’m a company of one, and I use SSO for my own accounts. I also set it up for clients as part of my Serverless Launchpad service for teams starting to build a new serverless app.

SSO brings several benefits in terms of security and ease-of-administration:

1. Short-lived credentials — IAM users requires persisting the same access key and secret on your workstation (usually in the ~/.aws/credentials file) which is used for all authentication requests (potentially indefinitely). SSO, on the other hand, issues temporary credentials at auth-time with an expiry configurable between 1 and 12 hours, and so if compromised, the risk is much reduced.
2. Multi-account access — IAM users are tied directly to a single AWS account. So if you need to access multiple accounts (say dev and staging), you need to create separate users for each. This can quickly get painful to administer. A single SSO user, however, can be granted access to all accounts within an AWS Organization.
3. Role-based access control per account — SSO has the concepts of Groups and Permission Sets. Users get added to a Group which maps to their team role, e.g. “Developers”. A Permission Set defines IAM policies which are applied to an authenticated principal in an account. The SSO administrator can then allocated Group + Permission Set pairings to specific accounts. This allows access to certain accounts (e.g. the root management and production workload accounts) to be restricted (e.g. to ViewOnly or blocked altogether). Session times can also be set lower for these higher-risk accounts.

By default, SSO is configured to use its own built-in identity source, and this works well for small teams. However, you can also configure it to use your company’s own user directory service (such as Microsoft Active Directory) if you so wish.

One thing which has constrained SSO adoption is the lack of support in tooling. The Serverless Framework CLI for example, doesn’t support SSO directly and so requires developers to perform some manual workflow steps to load in the temporary credentials in your terminal before running sls deploy (or using a secondary tool to help). However, the AWS JavaScript SDK (on which the Serverless Framework and other dev tools such as the AWS CDK depend) has just added support for SSO. If you use the Serverless Framework and would like to accelerate its addition of SSO support, please give a thumbs-up reaction to this GitHub issue. And if you use another dev tool that you’d like to get SSO added to, consider replying to Ben Kehoe’s thread.

For non-human user authentication into AWS, the requirement for IAM user creation is also declining. For example, GitHub Actions recently announced support for OpenID Connect to allow GHA workflows used in a CD pipeline to authenticate into AWS using temporary credentials.

In summary, if you have more than one AWS account in your company (which you really should if you’re running any production workloads), you should strongly consider using AWS SSO instead of IAM users.

— Paul

P.S. I won’t be sending an email tomorrow as I’m taking the day off to celebrate St. Patrick’s Day. Enjoy it if you’re celebrating too. ☘️