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 files. That was a big waste of time and productivity for developers. ~/.aws/** 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 with , , and , but generate temporary credentials for each call. This is not a bad thing in itself. ~/.aws/credentials aws_access_key_id aws_secret_access_key aws_session_token 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: GitHub AWS CDK Issue 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 files are accessible freely inside your local System. ~/.aws/** 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: Noovolari Leapp 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 , , and , in a secure, encrypted place inside your local system. aws_access_key_id aws_secret_access_key AWS SSO ACCESS TOKEN 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 files, in the straightforward form, with AWS access key, AWS secret key, and AWS access token. ~/.aws/** 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 , and . IAM Users, cross-account Role-based Access 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 is a must-read for you. Cloudonaut Previously published at https://www.itscava.com/aws-single-sign-on-for-devops-is-cli-v2-the-best-option
