Set up AWS Single-Sign-On (SSO)
Category: Cloud Platform
March 15, 2022 by Andre Verheij
For AWS customers that use multiple AWS accounts, part of an AWS Organisation, we recommend using AWS Single Sign-On (SSO) for easy access to these accounts.
There are several benefits to using SSO. As the name suggests, you use a single sign-on to the environment and with that you get access to the multiple AWS accounts that your user account is linked to. So you only have one username/password combination to remember.
AWS SSO also allows the use of Multi Factor Authentication (MFA). So next to the username/password combination another factor of authentication can be used, like hardware tokens such as a YubiKey.
Even if you don’t use AWS Control Tower, we always suggest implementing AWS SSO. This way, you don’t have to manage multiple IAM user accounts and their associated passwords for all the AWS accounts you have. Trust us, we have been there, done that and even have t-shirts.
Why is it important to have AWS SSO
Apart from AWS SSO being convenient, it’s also important from a security perspective. When people have access to multiple accounts with different usernames and passwords, it becomes difficult to manage. People start writing passwords down, try and use the same passwords. This then becomes a security risk, if the location where the passwords are written down is compromised. A better solution is to use a password manager. This is never a bad thing to be honest, AWS SSO doesn’t negate the usefulness of a password manager. The AWS SSO password still needs to be secure and complicated, too completed for humans to remember. Using MFA and a password manager to save a nice long 25+ long password securely is the way to go. That is a good “security posture”.
So how to get started
Firstly, you need to use AWS Organisations. Then go to AWS Single SignOn in the menu, then click on “Enable AWS SSO”. Simple right? Not long now!
Next step, define Identity sources.
When using AWS SSO, you can use the several different Identity Sources, AWS SSO has one built in, but you can also use Microsoft Active Directory, Azure AD, Okta and a few others. If you don’t have one of these Identity providers, no worries. As mentioned, it has a “directory” built in for users and groups.
After the Identity sources, it’s time to define permission sets.
What is a “permissions set”?
These are groups of Identity and Access Management Policies that define the level of access users and groups get in AWS accounts. When a user or group is assigned to an AWS account, you then link a permissions set to this Group or user.
In these permissions sets, you can use custom policies or use AWS provided ones. It’s always best to use the concept of “least privilege” so be careful not to allow too much to start with. Best not to give administrator access to start with.
So for Dev and prod you can create different permission sets, for example DataEngineering and DataEngineeringProd. In Dev, the users have full access to DynamoDB and in production ReadOnlyAccess.
How to handle users and groups?
Users are the individuals in your organisation. They have a username/PW to login and these users should be assigned to groups. Then these groups get access to AWS accounts for the roles that these groups are doing in those accounts.
For example, a member of the Data Engineering team, will be in the DataEngineering Group. This group is assigned to the dev-data and prod-data AWS accounts (as we call them in the cloudseeder Cloud Platform. )
So when a data engineering member logs in to the AWS Console using AWS SSO, they will only see two accounts, dev-data and prod-data. With the correct access permissions.
After this type of setup for the Data engineering team, you can do the same for other groups. While it’s not possible to create groups or users via Cloudformation templates, it is possible to create the Permissions Sets, Link groups or users to permissions sets that then can be linked to AWS accounts, via Cloudformation.
There are examples of shell scripts that show how you can create accounts and groups in bulk, from a CSV file. We’ll go into this in a later blog post.
Automating the creation of groups and users depends on the type of Identity source you have and this is where you use a mechanism called SCIM, which we’ll also discuss in a later blog post.
Does AWS SSO solve anything?
Yes, it certainly does. It’s a best practice way to manage access to AWS resources that is also ready for future expansion. A single username-password combination, added to that using MFA there is a good level of protection setup for your users, all while centrally managed from the AWS SSO console.
Want to learn more? Contact us here!