Amazon Elastic Container Registry (ECR) is a fully managed Docker container registry that allows developers to store container images securely. It does so by storing them in an ECR repository, a logical separation for storing, organizing, and versioning the Docker images inside an ECR repository. In a typical containerized application CI/CD pipeline, the Continuous Integration (CI) process builds, tags, and pushes the Docker image to an Amazon Elastic Container Registry (ECR) repository. Subsequently, the Continuous Delivery (CD) process provisions a container, task, or service from the Docker image (stored in the ECR repository) and deploys it to a container orchestration platform like an Amazon ECS cluster.

Application development teams manage multiple product environments—Dev, Test, Stage, and Prod—to ensure isolation, security, governance, and management. In this setup, it is common to adopt a spoke-and-wheel architecture, where an Amazon ECR repository (acting as the hub) is shared across various container hosting environments (such as Amazon ECS clusters) located in different AWS accounts. This architecture is achieved by hosting the ECR repository in one AWS account and deploying ECS services for each environment in separate AWS accounts. To enable cross-account access, specific AWS IAM permissions must be configured in both the ECR and ECS accounts. While Amazon ECR is commonly used for storing Docker images, managing access across multiple AWS accounts can be tricky. In this note, I explain the Terraform configuration to apply to the AWS account hosting the Amazon ECR repository and the AWS account hosting the Amazon ECS service.

I classified the use case into four sections. #1: Provision the pre-requisites in the AWS account hosting the Amazon ECS Service #2: Provision the Amazon ECR in the Central AWS account #3: Create a CI process to push Docker images to Amazon ECR #4: Provision an ECS service in the AWS account hosting the Amazon ECS Service

You can check the code in my GitHub repository: add-aws-ecr-ecs-fargate. Please note that the branch name = central-ecr.

#1: Provision the pre-requisites in the AWS account hosting the Amazon ECS Service I covered this section in detail in my note -create infrastructure to host an Amazon ECS Service using Terraform. There is, however, one change. In that note, I provisioned an Amazon ECR repository in the same AWS account hosting the Amazon ECS Service. So while following that note, please ignore the Amazon ECR provisioning process.

#2: Provision the Amazon ECR in the Central AWS account I provisioned an Amazon ECR repository and policy and an AWS KMS key and policy in the Central AWS account using Terraform. If you are following along, please check the files in the app\tf folder in the central-ecr branch of the GitHub repository.

The resources to provision in the AWS account to store the Amazon ECR image: 1. Amazon ECR to store the Docker image An Amazon ECR repository is where the (Docker) container images are stored. The image_tag_mutability property states whether the same image tag can be reused. Setting it to IMMUTABLE = same image tag cannot be reused. The encryption_configuration stores the KMS key details to encrypt the Docker images stored in the repository.

2. Amazon ECR repository policy to control access to the Docker image The Amazon ECR policy controls access to the Amazon ECR repository. In this case, the policy allows the local.development_env_root_arn to communicate with the Amazon ECR to download the Docker images. The value of the local.development_env_root_arn is the root arn of the Development environment AWS account.

3. AWS KMS key to encrypt the Docker image stored in Amazon ECR Amazon Elastic Container Registry (ECR) allows the storage and management of Docker images securely, and integrating it with AWS Key Management Service (KMS) enhances image protection by enabling encryption at rest. By enabling KMS encryption for the ECR repositories, cloud engineering teams can ensure that all images are encrypted using customer-managed keys, giving the team complete control over access and encryption policies. This integration helps safeguard sensitive data within container images and supports compliance with security standards.

4. AWS KMS key policy to control access and usage of the key A KMS key policy in Amazon Web Services (AWS) defines who can access and manage a specific KMS key, ensuring that only authorized entities can use it to encrypt or decrypt data. By carefully configuring the KMS key policy, cloud engineering teams can enforce strict security measures, ensuring that only the intended applications and users can interact with the encryption key and providing granular control over sensitive data in services like Amazon ECR. I used GitHub Actions to provision these resources. Hence, I created an IAM role in the Amazon ECR account with an Open ID connect trust with GitHub. You can learn about that at -securely integrate aws credentials with github actions using openid connect. Below is the image of the IAM role, which shows that it has a trust relation with the GitHub repository we’re referring to. This role had the AWS Managed AdministratorAccess permission policy attached to enable resource provisioning and the trust policy to enable usage via GitHub. I stored the ARN of this role as a GitHub secret and referred to that in the GitHub Actions pipeline stored at .github\workflows\terraform-ecr.yml as CENTRAL_ACCOUNT_IAM_ROLE. #3: Create a CI process to push Docker images to Amazon ECR I covered this process in detail at -Build, Scan, and Push Docker image to Amazon ECR using GitHub Actions.

#4: Provision an ECS service in the AWS account hosting the Amazon ECS Service I covered this process in detail at -Continuous Deployment of Amazon ECS service using Terraform and GitHub Actions. However, there is one additional requirement -the IAM policy attached to the task execution role in the ECS Service AWS Account also requires permission to access the Amazon ECR in the Central AWS account and to decrypt the Docker image using the KMS key in that AWS account. Both these permissions are enabled using the IAM policy. That brings us to the end of this note, where we’ve explored the process of setting up cross-account Amazon Elastic Container Registry (ECR) access using Terraform and GitHub Actions. By provisioning resources in both the ECR and ECS accounts, we learned how to securely share Docker images stored in a central AWS account with ECS services running in separate AWS accounts. We also learned how AWS Key Management Service (KMS) can be integrated with ECR for secure encryption, and how IAM roles and policies are crucial in granting the proper permissions to access resources across accounts. Finally, we walked through the CI/CD pipeline where Docker images are pushed to ECR and deployed to an ECS service in a separate AWS account. With this setup, you can efficiently manage containerized applications across different AWS accounts, ensuring security and scalability. Try out the Terraform code and GitHub Actions pipeline from the linked GitHub repository, and explore how you can further optimize your containerized workflows. If you have any questions or suggestions, please comment below.