Feb 23rd, 2021

How to Enable Cross-Account Access to Your AWS Account

#AWSIdentityandAccessManagement

#CrossAccountAccess

AWS Identity and Access Management (IAM)

Any AWS account’s journey starts with creating users, the root account user and the IAM users. Continuous management and monitoring of user access is key to maintaining a secure AWS subscription to protect your data. AWS IAM service is the central place to manage users, groups, roles and access policies. You can create and manage IAM users and grant permissions for those IAM users to access your resources.

Proper IAM Management is the key to AWS Security. Misconfigured IAM permissions and policies can compromise your resources to attackers. General rule of thumb for managing IAM is to follow the“principle of least privilege”. This principle requires limiting privileges to the minimum necessary to perform the job or task.

IAM misconfigurations can lead to:

  • Bitcoin Mining on compromised EC2 instances (Tesla Case)
  • RDS Database deletion, Ransomware Activities
  • Account hijacking
  • S3 Bucket Exposure and more...

IAM could be used with other AWS services to improve AWS environment security. For example, AWS CloudTrail is used to track user activity and API usage of IAM users. That's why we recommend setting up the AWS security services that could be used with IAM such as Access Analyzer, AWS CloudTrail, GuardDuty, Security Manager, etc.

image shows that the developer is using multiple AWS Services

 

Cross-Account Access Management with “Assume Role”

Illustration shows that cross-Account Access Management with Assume Role

 

IAM can also be used to establish access from one AWS subscription to a different AWS account. This is done with assuming a role from the other account. Some scenarios where you would need cross-account access:

  • A 3rd party cloud service that needs to make API calls to your AWS account.
  • A DevOps Engineer has been asked to separate Dev/QA/Production environments to separate AWS accounts and you do not want to manage different set of IAM users in each subscription.
  • An Auditor needs to analyze an entire AWS account AWS account to perform a security audit and identify issues with your configuration.

Whenever you perform an action in your AWS subscription, your request to a service is checked against the permission policies you have attached to your account. These policies can be coming from your IAM User policies or you can inherit them from the IAM Groups that you are in.

An IAM Role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. You can use IAM roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.

Creating an IAM Role requires 2 steps:

  • Selecting a Trusted Entity (it’s Trust Relationship for cross-account access)
  • Creating the permission policy of your resources for the IAM Role

Trusted Entity can be another AWS account, 3rd party SaaS, or another AWS service inside your account. After we create a IAM Role, these Trusted Entities can inherit the IAM Role’s permissions by assuming the role we created. IAM Entities can assume roles on the AWS Console or CLI.

A Real Use Case Scenario: IAM Cross-Account Access for Security Auditing on AWS

Illustration shows IAM Cross-Account Access for Security Auditing on AWS

 

Q: Why would I go through the whole process of role creation and assuming that role?

Let’s say you are in a Cloud Security team and you have many clients who need to audit their AWS Security. To get access to client’s AWS account there are two questions you need to answer:

  1. Which permissions does the security team need?

The permission list will differ from project to project, but let’s say that the security team will need at least read-only access to the client's entire AWS environment.

  1. How will the security team be granted access to the AWS environment with the defined permissions?

The two most common approaches are: Creating an IAM User: The client can create a new IAM user for the security team and manage its access there. However, in case of the trade-off of individual IAM user creation, the security team would have to manage at least one account per client. Also, the security team would have to share the credentials to designated IAM users on the client’s AWS. This approach adds authorization management workload to the security team.

Creating an IAM Role: The client creates an IAM Role with the required permissions to perform a security audit and allows that role to be used from the security teams account. Security team can have a central IAM subscription and have all the clients create a trusted relationship with the central account. The IAM user accounts for each individual team member can be managed in the central IAM account, as well as all other security requirements such as password complexity and MFA requirements. Inside this central IAM account, who has access to which customer’s account can be managed centrally using “assume role” capabilities.

Note: AWS Central IAM Account is a central and isolated AWS account that only stores IAM resources. Users in the IAM account cannot access any resource on their account but can access the resources in other accounts by assuming IAM roles into those accounts.

If an IAM Role will be created for cross-account access:

  • Security team members will have individual IAM accounts,
  • All cross-account access will be managed under central IAM account,
  • Team members’ assume role access to different clients’ accounts will be managed centrally.

It’s clear that managing a team member’s access to multiple AWS accounts with AWS Roles is the way to go. It’s more manageable and less prone to security risks. This article also provides a demo to create such access in AWS.

Demo: Cross-Account AWS Access with Assume Role

What Do We Want to Achieve with this Demo?

We want to access client’s AWS environment from AWS Security Auditors IAM users’ accounts. To do this:

  • We should create a role on the client side.
  • We should create a group and attach a policy for AWS Security Auditors IAM users.
  • Switch roles on Security Auditors side and read/list client’s AWS environment resources.

The logical architecture of this demo should be as follows:

Illustration shows architecture of accessing client’s AWS environment from AWS Security Auditors IAM users’ accounts.

The Logical Architecture of the Demo

 

  • Security Auditor IAM Users switch assumed role on AWS Management Console or AWS-cli and gain whatever permissions are assigned to that role.
  • Roles talks to AWS STS (Secure Token Service) to get IAM user credentials.
  • STS provides limited, temporary credentials (access keys, secret keys) to IAM users. IAM users can use these credentials to access the AWS resources that are allowed in related roles.

Client-Side

First of all, client’s team should construct CrossAccountSecurityAuditRole on AWS account for security auditors. The team should add a trusted entity in this role with “Account ID”. “Account ID” is the security auditors account ID. Additionally, client’s team should enable the “require MFA” option for security issues.

Screenshot shows how to construct client’s team CrossAccountSecurityAuditRole on AWS account for security auditors

 

On the next page, the client team should select policies for attaching to the role. For security auditing, AWS managed SecurityAudit policy could be used.

Screenshot shows that client team should select policies for attaching to the role

After these configurations, role name and description should be defined and role should be created on the review page. Screenshot shows role name and description are defined and role is created on the review page.

Security Auditor Side

On Security Auditors’ AWS environment, different IAM user groups (Security-Audit Group, Dev Group, Admin Group etc..) should be constructed. These groups have different purposes on AWS. For each group, teams should create policies to access client’s AWS account with a role. Security Auditors’ account should be located in the SecAuditors group and the policy should be attached to this group. The policies should provide client’s accountid and client’s rolename control with AssumeRole action. A security audit example policy should be generated below:

 {
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": [
            "arn:aws:iam::123456789123:role/CrossAccountSecurityAuditRole"
                    ]
            }
}

How to Switch Role and Cross-Account Access?

After all configurations, Security Audit IAM user could use company AWS account resources with these roles. To do this, Security Audit IAM users can sign-in to the console using the IAM user name and then switch role to access the client's account without having to enter another IAM username and password.

Screenshot shows Security Audit IAM user could use company AWS account resources with these roles

Screenshot shows that signing-in to the console using the IAM user name and then switch role to access the client's account to use Security Audit IAM user

If you liked this post, share it now!

Our Recent Posts

How to Secure Your Docker Containers: Tips and Challenges

Discover Docker technology, learn about Docker security best practices and Docker vulnerability...

Read More

Ultimate Guide to Securely Deploy Django at Scale on AWS ECS [Part 3]

Learn how to securely deploy a dockerized Django application to AWS Elastic Container Service w...

Read More

Ultimate Guide to Securely Deploy Django at Scale on AWS ECS [Part 2]

Learn how to securely deploy a dockerized Django application to AWS Elastic Container Service w...

Read More