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:
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:
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.
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.
Let's start from the beginning.
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.
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.
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!
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".
Now switch on the landing account ("Account B") and create a role that the user "john.doe" can assume.
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")
Adding the Gateway Account...
On the developer side, at this point, the only credentials needed to access to every account are the "Access key I.D." and "Secret access key" of the User in the Gateway account ("Account A").
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 "Access key I.D." and "Secret access key" in the System Vault (like "Keychain" for MacOs, "Credential Vault" for Windows, and managed by "Secret Service API/libsecret" in Linux)
That's the advantage of using Leapp over storing Credentials in the ~/.aws file.
In Leapp, under the "AWS" provider and the "Plain" access strategy, we are going to fill in all the needed info to connect to our Gateway Account:
Now our credentials are secured, and we can create a credentials session with this User directly from the Desktop App.
No more credentials are needed to access a role in a Truster account!
So, simply add a new session:
By selecting "Truster" 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, "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 STSAssumeRole call to retrieve the pair of access key and secret key needed to work on the current role.
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? Check out the Repo to meet the project and follow its development.
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