Managing AWS Cross Account Security Access
The introduction of AWS Organizations has enabled enterprises to move from single account model to multiple accounts grouped by organizational units (OUs). Enterprises can create their own hierarchical grouping of accounts using AWS Organizations to meet budgetary, security, or compliance needs.
A typical example of how an enterprise can define AWS Organizations structure is shown below:
The above structure consists of a Master account that manages the entire AWS Organizations structure. It is further classified into 3 Organization Units (OUs):
Management OU : This hosts Audit and Security Accounts. The Security Account would primarily contain all the enterprise IAM users and groups.
Development OU: This contains the Development and Sandbox accounts used by dev teams.
Production OU : This contains pre-prod Staging and Production accounts used by support teams.
This kind of structure facilitates grouping of similar accounts, applying common policies and sharing common resources. However, this also leads to the need for managing cross account access to resources. For example, users in security account would need access to resources in Development or Production account. There are a couple of ways in which cross account access can be granted and managed. We will discuss these approaches in detail in below sections.
Approach 1: Cross-Account Access using Roles
In the below figure, an IAM group named Developers in Security Account is trying to access S3 bucket from Development Account.
There are 2 key terminologies to understand here -
Trusting Account : This is the account that owns the resources that need to be accessed.
Trusted Account: This is the account that contains an IAM user, group or AWS service that is trying to access the resource present in Trusting Account.
Below are the steps for setting up cross account access:
Trusting account configuration (Development Account):
An IAM Role — allow-s3-full-access has to be created in Development Account to allow groups or users from Security Account to access resources (S3 bucket here) from Development account.
This role will have 2 policies attached to it:
Permissions policy: Defines what access the user of the role will have to the resource, in this case S3 bucket. Attach an AWS managed S3FullAccess policy to the role.
Trust policy: Lists the trusted entities that will assume the role. The below policy allows all users of group Developers of “trusted” Security account to assume role.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::<trusted-accountId>:Developers" },
"Action": ["sts:AssumeRole"],
"Condition": {}
}]
}Trusted Account configuration (Security Account):
The IAM group — Developers that needs to access to S3 bucket from Development account must be given permissions to assume the role by attaching below Permissions policy to the group. The Resource element contains the ARN value for the trusting account role: allow-s3-full-access. Users who need access to assume the role are added to Developers group .
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["sts:AssumeRole"],
"Resource": "arn:aws:iam::<trusting-accountId>:role/allow-s3-full-access",
}]
}How it works?
- User of Developers group tries to access Development account with the Assume Role permission granted to the group.
- AWS STS verifies the the request with the roles trust policy to ensure that the request is from a trusted entity (Development account). After verification, AWS STS returns temporary security credentials.
- The temporary credentials allow access to the AWS resource (S3 bucket). The user can then perform read, write and other operations on S3 bucket. With this temporary credentials user can only perform actions on S3 bucket and no other resources in Development account.
Approach 2: Cross-Account Access using Resource based policies
Resource based policies are attached to a resource instead of an identity.
The above figure depicts users in Developers group trying to access S3 bucket in Development Account. In this approach the resource based policy is attached to S3 bucket.
Below are the steps for setting up cross account access:
Trusting account configuration (Development Account):
Resource-based policy needs to be created which defines the maximum access that can be granted to “trusted” Security account.
Below resource-based policy grants access to Security account for performing List and Get operations on Development account S3 bucket.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal" : {"AWS": "arn:aws:iam::<trusted-accountId>:Developers" },
"Action": ["s3:ListBucket", "s3:GetObject"],
"Resource": "arn:aws:s3:::<bucket-name>, arn:aws:s3:::<bucket-name>/*",
}]
}Trusted Account configuration (Security Account):
Users in trusted account need to be given permission to perform actions. Define the below policy and attach it to Developers group. All users belonging to Developers group can then perform List and Get operations on the S3 bucket in Development account.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:ListBucket", "s3:GetObject"],
"Resource": "arn:aws:s3:::<bucket-name>, arn:aws:s3:::<bucket-name>/*",
}]
}However, it should be noted that both trusted account permissions policies and resource based policies need to Allow access to a resource. If either of them does not have a specific action, then access for that action would be denied.
Comparison : Role based vs Resource based
In Role based access, when a user assumes a Role for another account, the user loses its current account permissions and only retains the permissions granted for that role.
In Resource based policy access, when a user is accessing a resource from another account, the user retains all the permissions for current account. Resource policies can only be applied to the resources that currently support resource-based policies.
Conclusion:
In this article, we have seen how cross account security can be managed using role based or resource based approach. While both approaches enable users to access cross account resources, the choice of approach depends on the use case. Resource based policy has an advantage over Role based in that the principal still works in the trusted account and does not have to give up current account permissions to receive the role permissions. However, it does have a limitation that it can be applied only to resources that support resource-based policies. Role based approach can be applied to all the resources. The details of both the approaches learned in this article can help decide which approach to consider based on use case.
References and Further Reading:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html