The Trials and Travails of AWS SSO
Our newest Principal Cloud Economist Alex Rasmussen hails from a data engineering background. This is a capability that we and our consulting clients have increasingly needed, but his experience means that he’s been focused on different specific areas of the AWS universe than we have. As a result, he’s had some great questions for us as he’s been going through his onboarding that folks with a more “mainstream SRE” background have previously taken for granted.
One that caught my eye was around getting access to our internal AWS accounts. Specifically, he said “this is a very different and remarkably polished way of getting access to accounts. Is that an artifact of something internal we’ve done, or is there something else going on?”
A quick back-and-forth later established that he was used to what many folks were in the sense of a “traditional” granting of access to AWS accounts: “here’s your username and password, here’s your IAM credentials, at first login it’s going to yell at you to change your password and set up MFA” is the best case for this process. Often the IAM policies bound to the user’s account don’t permit self management of MFA devices, the password isn’t set to automatically demand a refresh at first login so the credentials that were shared become permanent, and so on. If you’ve been around the AWS block a bit, this is no surprise to you; in fact, it’s a rather depressing dance we all go through.
For internal accounts we instead have been using AWS SSO almost by accident for a while now, just because it came along for the ride when I used AWS Control Tower to provision our AWS Organization’s account structure.
The Good Parts of SSO
There are great reasons to adopt SSO, and I do endorse the pattern.
First, it keeps us from having to have persistent credentials on disk. The ephemeral credentials that SSO provides to us are only valid for the duration of the session; they’re not going to be hanging out in ~/.aws/credentials for anything overly nosy to snoop into.
Further, the login flow is pretty great. To sign in at the start of the day, we go to an account-wide URL which demands a username, a password, and optionally a demand for an MFA keypress or token. Unlike IAM users, multiple MFA devices are supported, and there’s an option to trust the browser you’re using so you aren’t asked to reauthenticate via MFA every time you log in.
Unlike role chaining IAM roles, we aren’t limited to an hour per session. Instead, the default timeout (both in browser and for ephemeral credentials in the CLI) is twelve hours. In effect, this grants us “log in once a day” levels of convenience instead of “it’s been an hour, surprise your command just failed” headaches.
The Areas for Improvement of SSO
Regardless of whether or not you use MFA to log in, your session lacks the MultiFactorAuthPresent attribute; therefore, any role assumption or other IAM restrictions that require it will not permit the SSO’d user to perform the requested action.
Also, IAM is global while SSO is single-region. If it’s impacted in that region, guess who can’t log in to their AWS account? That’s right, your entire company.
And of course, in its effort to remain on-brand for AWS, the user experience is sub-par for using it day to day. That said, there are some tooling options to make it better.
Ben Kehoe has created aws-sso-util, a utility that’s intentionally designed to be a thin layer on top of AWS’s offering so as not to diverge from the AWS service vision as it continues to evolve. Despite the noble intention, Ben misses the mark here; to truly remain aligned with AWS’s user experience this tool would instead require you to type the full access key, secret key, and session token into your terminal by hand after disabling your ability to copy and paste.
Aaron Turner has created aws-sso-cli an opinionated CLI helper that offers tab completion, the ability to launch shells with the proper environment variables set, and a much more polished experience. It even supports multiple SSO organizations, for those of us who do unholy things with our AWS accounts.
And I’d be remiss if I didn’t point out that aws-vault didn’t also support AWS SSO super well once you’ve configured the relevant profile within your AWS config file.
The Takeaway
I really like AWS SSO. I wish that I didn’t have to work with IAM credentials as well, and could migrate everything over to using it. As it stands my options today are to use both methods for different things, dream of a better world, and try mightily to resist the temptation to build some obscene “portal” that lets SSO users access vended IAM MFA’d credentials as needed to assume roles where they’re required.
As for Alex, he’s almost certainly very sorry that he asked the question.
