Considered to be the best practices in AWS, one of the most popular ways to maximize AWS's potential is to utilize multiple accounts. An account enables you to run multiple workloads and draw a line on three crucial aspects: Billing and Cost Management Identity and Access Management Limit Resources and API Request Management Firstly, AWS encouraged creating multiple accounts, developed Consolidated billing to group all the billings of an AWS environment. Then, in 2017, it introduced AWS Organization. If we focus on IAM and access management, with Organization, AWS SSO has come as a gamechanger for a large number of situations. Anyway, there are many circumstances where applying this kind of structure doesn't fit the needs, for example: , where the Identity Provider is locked up in many sub-companies: as the company grows, or if a company with his Identity Provider got acquired into another, unifying access in a single point can be significant pain. Large Companies If you are a consulting partner, you probably have to isolate Organizations for each customer you have, which can't be done with a single organization and a single AWS SSO. Moreover, in the case of reselling, centralized billing and reserved instances at the organization level doesn't work, too. Consulting partners: the need of getting isolation for the workflows through accounts is difficult to achieve, and the danger of a blast radius in case of breaches is enormous. More than 50 accounts Organizations: Even if AWS SSO provides several benefits, in such cases, the problem of managing multiple-account access remains. Also, using AWS SSO is not permitted if you are not the owner of ALL the accounts. This situation will cut out smaller companies acquired by bigger companies. The downside to using multiple accounts, without organization, is the necessity to provide various logins to each person that needs access. For example, each DevOps Engineer may have credentials to their sandbox account, internal company accounts, developer accounts, and client accounts. Providing a security best practice, such as password rotation or not reusing the same password between more accounts, could be challenging to apply. To manage this situation better, the help of STS and cross-account role-based IAM access is crucial. Cross-account role-based IAM access A single IAM Role can have specific permissions (i.e. development-role, marketing-role) into a single account. Then an IAM user can access a different account with a specific IAM role through STS with the AssumeRole action. This is the turning point. You can now isolate a group of accounts where a single organization entity manages access individually. Now isolating the environment in a workload is easy and it respects compliance. But still, there are many topics to pay attention to. The environment Let's start from the beginning. AWS IAM... If you still don't know what Identity and Access Management (IAM) are, here's a quick recap: AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to deny their access to AWS resources. So basically, it is the AWS framework that lets you decide who can access what on your account. Mastering this service is the first step in securing your AWS account, but let's see what IAM users are and why they are important. ... Users! This is the most widespread and easy access method in all AWS. An AWS Identity and Access Management (IAM) User is an entity you create in AWS to represent the person or application that leverages the account to interact with AWS. A user in AWS consists of a name and credentials. With a User, we are going to represent each person that has to access the Cloud services. This user should have only permission to assume some particular role in other accounts, so he becomes the permission manager on what account each developer can access. ... Roles A Role is the most versatile entity in AWS IAM. An IAM role is an IAM identity you can create in your account that has specific permissions. The fact that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS, makes it similar to an IAM User However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. We will manage what kind of permission it will have in an account at that particular moment with roles. So let's start! How to manage infrastructure On a Gateway account.. (AWS Account "A") We will create a User that will serve as a bridge to all other AWS accounts the person with this User needs to reach. Firstly create the User and then attach a policy with the only permission to assume a role in another account. The AWS policy should be like the one below. { : , : { : , : , : } } "Version" "2012-10-17" "Statement" "Effect" "Allow" "Action" "sts:AssumeRole" "Resource" "arn:aws:iam::123456789012:role/developer" With this policy, we are permitting the user "john.doe" to assume the role of "developer" in the account "123456789012". On the Truster account.. (AWS Account "B") Now switch on the landing account ("Account B") and create a role that the user can assume. "john.doe" N.B. remember to specify the truster identity, with the account id of the Gateway Account. Next, add the permission needed for the specific role. Through this simple tutorial, we have allowed "john.doe" to access the "developer" role in the Truster account ("Account B") What about the Developer side? Adding the Gateway Account... On the developer side, at this point, the only credentials needed to access to every account are the and of the User in the Gateway account ("Account A"). "Access key I.D." "Secret access key" Storing that info in a secure and encrypted place in your local system is essential. That's how Leapp comes to help. Leapp is going to save and in the System Vault (like for MacOs, for Windows, and managed by in Linux) "Access key I.D." "Secret access key" "Keychain" "Credential Vault" "Secret Service API/libsecret" That's the advantage of using Leapp over storing Credentials in the ~/.aws file . In Leapp, under the provider and the access strategy, we are going to fill in all the needed info to connect to our Gateway Account: "AWS" "Plain" Now our credentials are secured, and we can create a credentials session with this User directly from the Desktop App. The Truster Account So, simply add a new session: No more credentials are needed to access a role in a Truster account! By selecting as an access strategy, you only have to add info about the account ("Account B") alias and number, then the role name you have to assume, in our case, "Truster" "developer." After doing so, we have to select the account Gateway ("Account A") from where we access the "developer" role. With Leapp, when the session is set to active, the App is going to call the call to retrieve the pair of access key and secret key needed to work on the current role. STSAssumeRole Also, the credentials are frequently rotated without having to worry about them! In this article, we have described the right situation for the right environment. We walked through the configuration of Cross-account role-based IAM access both from the Manager and the Developer point of view. Curious about Leapp? to meet the project and follow its development. Check out the Repo Is this environment fitting with your company? Need any help in implementing it? Feel free to contact me! Previously published at https://www.itscava.com/aws-sso-vs-cross-account-role-based-iam-access-why-and-how-to-use-roles
