One of the most popular cloud computing platforms for businesses, Amazon Web Services (AWS), offers a variety of features to ensure the security of its users’ data. One essential aspect of AWS security is the proper management of Identity and Access Management (IAM) policies.

Today, we will discuss how to enable cross-account access to your AWS account using IAM and the “Assume Role” feature. We will also provide a real-world use case scenario and a step-by-step demo to help you get started.

Let’s get started without wasting time.

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 are 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. The 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.

AWS Identity and Access Management (IAM)

Also see: Introduction to AWS Serverless Application Model

Cross-Account Access Management with “Assume Role”

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 by 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 sets 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 for 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

A trusted Entity can be another AWS account, 3rd party SaaS, or another AWS service inside your account. After we create an 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

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 the 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 with 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 team’s account. The 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, you can manage who has access to which customer’s account 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 in 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 a 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 the 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 the Security Auditor’s side and read/list the client’s AWS environment resources.

The logical architecture of this demo should be as follows:

Cross-Account AWS Access with Assume Role

The Logical Architecture of the Demo

  • Security Auditor IAM Users switch assumed roles on AWS Management Console or AWS-CLI and gain whatever permissions are assigned to that role.
  • Roles talk 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.

This article may interest you: AWS SDK for Python Boto3 Cheat Sheet & Code Snippets

Client-Side

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

Client-Side

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.

Client-Side

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

Client-Side

 

Security Auditor Side

In 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 the client’s AWS account with a role. Security Auditors’ accounts should be located in the SecAuditors group and the policy should be attached to this group. The policies should provide the client’s account_id and the client’s role_name 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, the 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 roles to access the client’s account without having to enter another IAM username and password.

Switch Role and Cross-Account Access

Switch Role and Cross-Account Access

 

To sum up

Enabling cross-account access to your AWS account can be a valuable tool for both security audits and managing multiple AWS accounts. However, it is important to ensure proper IAM management to prevent misconfigurations that could lead to security breaches.

By following the “principle of least privilege” and utilizing AWS security services such as Access Analyzer and AWS CloudTrail, you can help ensure the security of your AWS resources.

We hope you find this article useful. With the step-by-step guide and real-world use case provided in this post, you should now have a solid understanding of how to enable cross-account access to your AWS account using IAM and the “Assume Role” feature.

Check out our Cloud Security services to stay secure. To learn more, contact us today and let’s talk about how we can help you.