Going back to the 10 of December 2017, AWS introduced AWS Single Sign-On, a service that makes it easy for you to centrally manage SSO access to multiple AWS accounts and business applications.

Three years later, the Service has grown a lot, and with the increment of usage of services like AWS Control Tower and the AWS Organization in general, AWS Single Sign-on has been one of the best methods proposed by AWS to manage access in a Multi-Account Cloud environment.

But, in the first instance, users were supposed to log into the AWS SSO portal, copy the named profile credentials and paste them into their local ~/.aws/** files. That was a big waste of time and productivity for developers.

Later on, in 2019, AWS introduced the CLI V2, in beta preview, with the native support of AWS SSO.

That's been a huge leap for developers because the release included automatic short-term credential rotation enabling developers to take full advantage of CLI profiles to switch between roles, which increases their security posture.
So, let's see the good, the bad, and the ugly of this proposal.

The Good

With this integration, Developers can now initiate the same SSO flow as the portal, but with different results.

The CLI will automatically generate temporary credentials from an access Token that will last 8 hours.

Also, it applies named profiles for each access role you need.

By doing so, developers can change their account by switching the in-use AWS named profile.
The automatic short-term credential management enables developers to switch between accounts and roles seamlessly without refreshing credentials.

To run a command that refers to a particular AWS profile, you have only to add the --profile parameter:

aws s3 ls --profile my-profile

The Bad

The process is relatively easy on the developer side, but it still brings some issues.

From the CLI, you can list all the accounts you can access via AWS Single Sign-On, but you don't have the complete picture of the situation: which Role can you access in that specific account? This is not a single process via the CLI, and in most cases, that can be a significant effort.

On the credentials side, this method doesn't generate a classic AWS Role credential inside the ~/.aws/credentials with aws_access_key_id, aws_secret_access_key, and aws_session_token, but generate temporary credentials for each call. This is not a bad thing in itself.

This credential method, via CLI, is still in Beta preview, and lots of open-source projects yet don't support it.

There are still many issues online on those class of problem:

AWS SSO Named Profiles Support #5455

vikyol posted on Dec 17, 2019

AWS CLI v2 supports AWS SSO named profiles.

However, CDK CLI cannot resolve SSO named profiles yet.

$ cdk deploy --profile sso-named-profile

Unable to resolve AWS account to use. It must be either configured when you define your CDK or through the environment

Without this feature, users have to login to SSO user portal and fetch credentials for command line and CLI access, which needs to be repeated every time the credentials expire.

Even though CLI v2 is still in preview, it would be good to have this feature implemented for early adopters.

Use Case

• Simplify deployments to multiple-accounts for AWS SSO users.

Proposed Solution

• Read sso_start_url, sso_role_name and sso_account_id from ~/.aws/config file.
• Fetch the accessToken in ~/.aws/sso/cache/ matching sso_start_url.
• Fetch temporary credentials from STS using SSO.get-role-credentials() with accessToken, sso_account_id and sso_role_name parameters.

---

This is a 🚀 Feature Request

View on GitHub

The Ugly

Last but not least, let's identify the sore points.

Once you have been logged into the portal, in the ~/.aws/sso/cache/** you will find 2 files:

The first contains the local client id, which is required to make every API call to the AWS Single Sign-On portal, and the other includes an ACCESS TOKENthat is valid for 8 hours.

With those two objects, you can access EVERY account you can reach through AWS Single Sign-On.

That means that if someone steals your credentials files, he can access all your accounts via AWS SSO!

And the most painful part to me is that the ~/.aws/** files are accessible freely inside your local System.

We know really well that Striking a Balance between Security and Flexibility is Crucial.

But that was too much not secure in comparison to what we were gaining in terms of flexibility. So we came up with this new feature in our open-source project:

Leapp and AWS Single Sign-On

Leapp is a DevTool to increase productivity for everyone that will work with Programmatic access to the Cloud.

With Leapp, you can store all personal information, such as aws_access_key_id, aws_secret_access_key, and AWS SSO ACCESS TOKEN, in a secure, encrypted place inside your local system.

Leapp integrates AWS Single Sign-On is really a one Click process and automatically generate ALL the Session that a Developer can access, from a single view:

An important point here is that Leapp generates only short-lived temporary credentials in the ~/.aws/** files, in the straightforward form, with AWS access key, AWS secret key, and AWS access token.

By doing so, this makes every credential generated from AWS Single Sign-On with Leapp fully compatible with every Library and project that uses Programmatic access to AWS.

Also, AWS Single Sign-On is not the only credentials method supported by Leapp at the moment; it manages and also secures IAM Users, cross-account Role-based Access, and federated Access through GSuite.

Final Thoughts

Isolate workloads have become a good practice in AWS, and create an AWS Organization has become a standard in the last years.

How to access multiple and heterogeneous accounts has always been an overhead that has been simplified with AWS SSO.

But to me, is always important to keep an eye on the security side and that's why I would choose Leapp over accessing via the CLI directly.

If you aren't sure if the AWS Organization is the best option for you, I think the article of Cloudonaut is a must-read for you.