I would argue that the AWS SSO is a "hidden gem" of AWS service. With AWS SSO, you do not have to deal with AWS IAM Users and long-lived credentials.
I have a suspicion that there is a lot of misinformation about AWS SSO out there. Some common misconceptions I've heard are:
"You need OKTA to use AWS SSO".
"You have to use AWS Control Tower to use AWS SSO".
"The AWS SSO setup is complex, and only experienced AWS developers can utilize it".
None of the above are correct. I'm using AWS SSO for my personal AWS stuff, and I've never had to interact with AWS Control Tower or OKTA in any shape or form. It is entirely possible to have AWS SSO working with a bare minimum AWS Organizations and AWS IAM configuration, and this blog post will show you how.
The why of AWS SSO for AWS development
"Why should I bother using/taking my time to learn AWS SSO?" is a valid question, especially when time is the scarcest resource we have. My arguments in favor of learning/using AWS SSO follow.
The first point is that you do not have to worry about long-lived credentials for your AWS accounts anymore (except the root one), which drastically improves the security posture of your environment.
The second point is that if set up correctly, AWS SSO is extremely convenient to use. In my current personal dev workflow, all I do to obtain a time-bound AWS session is type one short command and pick the right account/IAM role combo.
The third point is that knowing just a little about AWS SSO could help you in your day job where you most likely use OKTA (or any other identity provider) with AWS SSO (If you are not, and the configuration you have works for you, more power to you). Someone had to know how to connect the services in the first place. That someone might be you :).
Setting the stage
Before we dive into the configuration itself, I think it is vital to set expectations regarding what I'm about to show you.
We will only use the bare minimum of AWS services/features for simplicity.
I would not recommend using this setup for your company's AWS SSO story. Look into combining OrgFormation / AWS Control Tower with AWS SSO for that.
I've tried to keep the complexity to a minimum so that people who are not familiar with AWS (for example, me from 3 years ago) can go through the listed steps without significant issues.
You will be using the AWS console through configuration steps. Creating an IaC template to automate the setup is beyond this blog post's scope.
The end goal
After you have completed the configuration steps, you will be able to do the following:
- Login into a given AWS account console with a single click via the AWS SSO user portal. Here is a screenshot of my AWS SSO portal dashboard.
- Assume credentials for a given AWS IAM role in a given AWS account for CLI usage with a single command.
Interested? Let us get started with the configuration.
The configuration
The prerequisites
- AWS CLI installed.
The steps
1 - If you do not have an AWS account already, create one. There are many great resources on how to do just that, for example, this guide by A Cloud Guru.
- I would strongly recommend this AWS account be used only for AWS SSO / AWS Organizations set up. Consider not running any deployments on this account.
2 - Pick the region you wish your AWS SSO configuration to be deployed into. To my best knowledge, the AWS SSO is a region-bound service. For demonstration purposes I will be using the eu-west-1 region throughout this blog post.
3 - In the search bar, look for AWS SSO service. The sso search phrase should do. Click on the service tile to go to its dashboard.
4 - After landing on the AWS SSO dashboard, assuming you do not have it enabled in any other AWS regions, you should be presented with a landing page that contains a big "Enable AWS SSO" button – click on it.
5 - Assuming you do not have any AWS Organizations created on this account, the AWS console will greet you with the popup to create one. Click on the "Create AWS Organization" button.
- If you are new to AWS and have no idea what AWS Organizations are, consider them a way of creating multiple AWS accounts with ease. You do NOT have to know a lot about them to configure AWS SSO. Consult the AWS Organizations documentation for more information.
After waiting a bit for the AWS console to create the AWS Organization, you will be redirected to the AWS SSO service dashboard.
6 - Next up, we need to create an AWS account we will be SSOing into (and assuming given policy in that account, more on that later). As I eluded earlier, we will be using AWS Organizations to manage AWS accounts. AWS SSO service created an AWS Organization for us in the previous step. Go to the created AWS Organization by searching for the service name.
7 - Next up, click on the "Add an AWS account" button.
We want to create a new AWS account.
Pick whatever name you want. My recommendation would be to add the "Development" suffix to the name to signal that this is the account I'm using for playing around – i.e., it contains deployed AWS resources.
I would leave the "IAM role name" default value. The permission model of AWS Organizations goes beyond the scope of this article.
I would not bother with any Tags for personal-only use.
8 - After you have successfully created the AWS account and set the password (the email you have received from AWS), it is time to go back to the AWS SSO dashboard to finish the configuration.
9 - Next, we have to create a permission set (a scary name for a collection of IAM Policies) you will be acquiring when SSOing into a given AWS account. This part is what allows us to ditch the long-lived credentials. Switch to the "Permission sets" tab and click on "Create permission set".
10 - Now comes the permission set creation wizard. The following are my recommendations for each step.
For the "Type" step, I recommend sticking with "Use an existing job function policy" unless you are adept at writing AWS IAM Policies.
For the "Detail" step, I recommend picking the "PowerUserAccess" policy. Make sure you understand what a given policy grants.
When it comes to the "Tags" step, I would not bother setting them for personal use, but I leave that decision up to you.
Tags are essential in a work environment where multiple teams operate on different resources.
11 - Next, we have to create a user that can sign in to an AWS SSO user portal. We will be associating the user with a permission set and AWS account later. To create an AWS SSO user, navigate to the "Users" tab and click the "Add user" button.
Make sure to save the username you specified in the "Specify user details" step – you will need it later on.
I would suggest omitting creating groups for simplicity's sake, but that is up to you.
After you have created the user, I would strongly consider adding an MFA for that user.
12 - With the AWS SSO user created, it is time to tie everything we have been configuring together. Navigate to the "AWS accounts" tab. We will be associating the AWS SSO user with a given permission set and an AWS account.
As with AWS SSO users, the AWS console uses a wizard-style form for this configuration. The following are screenshots that should help you navigate the steps.
Testing
Okay, we have done everything we need to make the AWS SSO work in its simplest, from – having access to an AWS account without using long-lived credentials. Now it is time to test our setup to ensure everything is working correctly. Let us start with AWS console access using AWS SSO.
AWS console access through AWS SSO
After finishing step 12 from the The steps section of this article, navigate to the AWS SSO "Dashboard" tab and copy the "User portal URL"
After signing in successfully (use credentials for AWS SSO user and NOT the AWS account), you should be able to pick the AWS account and the permission set combo, we have configured in the previous section.
The "Management console" link should redirect you to a given AWS account as a federated user scoped to a given permission set.
Consider bookmarking the "User portal URL" for easy access.
AWS CLI access
With the AWS console access out of the way, let us focus on AWS CLI access and getting the AWS credentials from the AWS SSO session.
Luckily for us, the AWS CLI already has excellent support for AWS SSO.
I find the official AWS CLI SSO configuration guide to be a very well-put resource on how to configure the AWS CLI with AWS SSO correctly.
After configuring the CLI, I recommend you look into aws-export-credentials for exporting the credentials as environment variables across different shells you use.
Possible improvements
One improvement that one can make to the configuration I presented is to encapsulate it within reproducible IaC deployment. This goes beyond my area of expertise as I'm more of an application developer that never had to deal with creating IaC code for AWS Organizations and AWS SSO.
If you feel like this is what you want to do next – great! I would start by reading on either AWS ControlTower or OrgFormation.
Closing words
I hope you find this blog post helpful as I would a couple of months prior when I had no idea what I was doing going through the process I described in the "The steps" section.
We configured AWS SSO for our development account with twelve steps and ditched the long-lived credentials associated with IAM Users in the process.
For more AWS / serverless content, consider following me on Twitter - @wm_matuszewski
And, as always, thank you for your valuable time.
Oldest comments (8)
Nice write up, it's good to see developers picking up on the security and convenience benefits of SSO. It is a region specific device as you suspect. Pro tip: avoid using us east 1 if you can, for SSO and everything else for that matter
Great and fast explanation!!! Thanks, this will be very useful to implement.
Great Article! Worked perfectly! Thanks!
For CLI access, I highly recommend trying leapp: leapp.cloud/
Thanks for the tutorial. I tried following, I have a question, it is possible the poweraccess user created can not load the root organization?
To be honest, I'm not sure. Maybe one could use SCPs (docs.aws.amazon.com/organizations/...) for that?
In my setup, I use SCPs to disallow any user, except the root user, to view billing-related data (like billing dashboard and so on).
I would recommend you play around with SCPs.
Thanks for the reply. I would check it out. I followed your exercise and got the notification. Tried giving several permissions to see if it would work, but would study the SCP. It was educative.
Great tutorial!
Thanks very much for putting this together.
But now it's April 2024 and it seems that AWS have shuffled things around and my AWS console looks different.
E.g. there is nothing for "SSO", I assume that it was renamed to "IAM Identity Center" but trying to map the instructions to the new look and terminology leaves a lot of room for guessing.
Would you know about a similar document with updated instructions?