Blog - Trusted Team Extension Partner For Europe & USA

Simplifying Cross-Account Communication in AWS: A Practical Guide - Best Software Development Team Extension Partner for Nordics

Written by Saimon hossain | 22/04/2024

In the fast-paced world of cloud computing, Amazon Web Services (AWS) is a popular choice for businesses looking to build secure, scalable, and strong applications.

As businesses expand in the AWS world, the need for effective cross-account communication becomes increasingly important.

This allows for central management, resource sharing, and smooth collaboration across multiple AWS accounts.

Understanding cross-account communication in AWS can be tricky, especially for those new to the platform.

But worry not! This guide is here to break it down for you. No matter your experience level, think of this guide as your helpful friend, assisting you in tackling the challenges of cross-account communication and getting the most out of your AWS setup. We’ll start by covering the fundamental theoretical aspects before delving into solving a real-world scenario.

 

Why Cross-Account Communication?

Cross-account communication is crucial in various situations within the AWS ecosystem. Let’s see why it matters:

  1. Workload Separation and Isolation: Organizations often spread their applications across multiple AWS accounts to better organize and protect their work. Keeping workloads in different accounts helps manage who has access, permissions, and where resources are used.
  2. Handling Scalability and Complexity: As organizations expand, managing all services within a single AWS account can quickly become chaotic. Cross-account communication acts as a solution, providing scalability and simplifying the management of resources. Think of it as building additional floors in a building to accommodate growth without overcrowding a single floor.
  3. Centralized Services: Certain services (e.g observability platforms, logging, monitoring) are centralized and serve multiple accounts.
  4. Security Boundaries: Cross-account communication is a powerful tool for controlling access while maintaining tight security measures. For instance, a Lambda function in one account may need to interact with an S3 bucket in another account. This ensures that actions are performed securely, with controlled access, similar to having secure checkpoints between different sections of a facility.
  5. Sharing Data Across Accounts: In collaborative environments, different teams or departments often require secure data sharing across accounts. Consider a scenario where a data engineering team in one account needs access to data stored in another account. Cross-account communication enables secure data exchange, fostering collaboration and efficient workflows. 

In essence, cross-account communication acts as a versatile tool, addressing organizational needs ranging from effective workload management and security enforcement to seamless collaboration and data sharing across the AWS ecosystem.

 

Enabling Cross-Account Access

AWS provides various ways to enable communication between different accounts. The key methods involve using resource-based policies and IAM roles.

 

Resource-based policies

Some AWS services, like S3, allow you to directly attach resource-based policies to the resource you want to share. These policies specify who (which principal) can access the resource. Unlike identity-based policies for roles, resource-based policies focus on the resource itself.

 

Cross-Account IAM Roles

Not all services support resource-based policies. In such cases, you can opt for cross-account IAM roles for centralized permission management. These roles include a trust policy that permits IAM principals in another AWS account to assume the role.

For more information on resource-based and identity-based policies, check out this AWS user guide.

Let’s transition from theory to hands-on problem-solving.

 

The Scenario

Imagine a situation where important assets, like video files, are securely stored in an S3 bucket within account A. Now, let’s say there’s a Lambda function in account B that needs to create pre-signed URLs for safe and authorized downloads of these assets. The difficulty here is in establishing a secure communication link between these two AWS accounts. The task is to ensure a reliable and protected means for the Lambda function in account B to access and generate pre-signed URLs for the assets stored in the S3 bucket of account A.

 

First things first: Setting Up Lambda with Roles and Permissions

Let’s create the Lambda function with the necessary roles and permissions in our AWS account (account B) using Terraform.

Lambda IAM role

IAM roles are crucial components in how users, services, and resources interact within Amazon Web Services. Unlike IAM users, roles don’t have long-term credentials but rely on temporary credentials generated during role assumption.

Here’s the Terraform code to create the IAM role for our Lambda function:

 

Lambda function

Now, let’s create the Lambda function using Terraform:

 

Lambda Role Custom Policy

In our account, we need to attach the following custom policy to the Lambda role. This policy explicitly grants permission for the Lambda role to assume the S3 Access role in account A.

 

Let’s create the policy and attach it to our presigned URL generator Lambda function.


Replace ACCOUNT_A_ID with the actual AWS account ID where the S3 bucket is, and S3ACCESS_ROLE with the name of the actual S3 access role.

 

Setting Up Trust Relationships

The trust policy defines which principals (entities) can assume a particular role and under what conditions. It is a specific type of resource-based policy for IAM roles focusing on the relationship between the role and the entities that trust it.

In account A, let’s create an S3 access role that has a trust policy allowing the Lambda role in account B to assume it, maintaining security boundaries.

Cross-Account IAM role for S3 Access

Imagine we have a bucket named classic-movies. Let’s create an IAM role for accessing the bucket, and attach a policy that allows permissions required for pre-signed URL generation of the movie objects. Also, we’ll ensure a trust policy is in place, permitting the Lambda role in account B to assume this newly created IAM role.

Replace ACCOUNT_B_ID with the actual AWS account ID where the Lambda function resides, and LAMBDA_ROLE_NAME with the name of the role associated with the Lambda function.

 

Role Assumption in Code

Once trust relationships are established, the Lambda function in our production account – account B can programmatically assume the S3 access role in account A using the AssumeRole API of STS. It’s important to note that, when we assume a role, we give up the original permissions and adopt the permissions assigned to the newly assumed role. 

Here’s how you can achieve this in Python:


Generating Presigned URLs

With the assumed role’s credentials, the Lambda function in account B can now generate presigned URLs for securely downloading movies from account A’s S3 bucket. Presigned URLs are short-lived and provide temporary access to the specified object.

Here’s how to generate a presigned URL using the assumed credentials:

 

 

Caveats: Role Duration Awareness

When working with pre-signed URLs, it’s crucial to be aware of the relationship between the pre-signed URL’s validity and the duration of the Lambda assumed role. Here are some important points to consider:

  • Presigned URL Expiration (ExpiresIn):
      • The ExpiresIn parameter in the pre-signed URL determines how long the URL remains valid.
      • We need to set the expiration time within the Lambda assume role’s duration. If the ExpiresIn exceeds the assumed role duration, the validity is capped at the minimum of the two durations.
      • For security reasons, we must avoid setting excessively long expiration times and choose a reasonable duration based on our use case.
  • Cross-account Role Duration:
    • The duration of the cross-account role assumed by the lambda function affects the overall security of the communication channel.

 

Lambda Implementation

Here’s the step-by-step guide to implementing the Lambda function using Python:

  1. Navigate to the src/presigned-url-generator directory.
  2. Create a new Python file named presigned_url_generator.py.
  3. Open the newly created file and insert the following Python function:


Assume the specified IAM role based on the given role ARN.

Generate a presigned URL for downloading an S3 object.

 

Lambda function to generate a presigned URL.

 

 

Let’s zip it

When deploying a Lambda function, AWS Lambda expects the function code to be packaged in a ZIP archive. Here’s how you can create a zip archive for the Lambda function using Terraform:

 

Once deployed, our lambda function can securely generate pre-signed URLs for us to download our favorite classic movies stored in the S3 bucket of account A. 

 

Conclusion

By carefully following the outlined steps and taking into account the duration of roles, we have effectively set up a secure communication link between two AWS accounts. This ensures that the Lambda function in account B can securely interact with the S3 access role in account A, enhancing the overall security and efficiency of cross-account communication. It’s similar to establishing a guarded pathway, allowing seamless and protected collaboration between different components of our AWS infrastructure.
View full post