Delegate Cross Account Access to Amazon ECR

There are many situations that we need to deal with different/multiple AWS accounts for different purposes. For an example, if we need to work with an enterprise software release process, we have to maintain different stages of the software deployment for maintaining and ensure the high availability with required security controls too. It is a good practice to separate out each different stages as per the development and deployment perspectives such as Dev stage, Staging stage, Pre-Prod stag, Prod stage, and even more as required. How AWS makes this easy is that we can maintain multiple AWS accounts and allocate one account for one stage in our software deployment process. Simply think that you can have dev-account for Dev stage, staging-account for staging stage, and so on as AWS accounts. This method decouples your deployment from stages and also there is enough capability to enhance the security at each stage and treat them individually.

Why and when do we need to delegate cross account access for Amazon ECR?

Let’s re-think about the scenario which was mentioned above. Say, we have a container based product deployment where we use Docker container images. We need to use these Docker container images in all stages and usually the image will be built in the Dev stage and propagate to other stages at deployment time. But, how this can be shared to other stages since those are in different accounts (deployment environments)?

As a simple solution, we can store the built Docker image in an Amazon ECR only in a single account. Let’s say we store it inside dev-account. All other environments need to retrieve the image from dev-account and use in their deployments. It is pretty straightforward to have such a decision since the image will be maintain at a single point and there will be no more unnecessary overheads at maintenance.

How AWS supports access delegation for this purpose?

There are set of policy types which are supported by AWS. Among them, resource-based policies are the most important type for this topic.

But, what is this policy? If you are quite familiar with Identity and Access Management, you may know what is an identity-based policy. Basically an identity-based policy defines set of permissions that the assigned IAM entity (user, role, or group) can perform. As in the same mean, a resource-based policy defines set of permissions that handles at the resource side defining what are the allowed actions and who are allowed to perform those actions on it. Refer to the following figure 1 below where it simply illustrates the difference.

Figure 1: Illustration for identity vs resource based policy with less context

Moving towards the topic back, consider using AWS CLI as the mean to access Amazon ECR by an IAM User. In order to perform push and pull actions against the required registry, both identity-based and resource-based policy will be used.

When access a registry using AWS CLI, the first thing is that there should be a active login to the registry for the particular user. Hence, the user should have an identity-based policy as below which allow IAM users to get a login to Amazon ECR. Note that AWS specifically mentions that “Resource”: “*” is the required level of permission to perform GetAuthorizationToken.

{
  “Version”: “2012–10–17”,
  “Statement”: [{
     “Effect”: “Allow”,
     “Action”: “ecr:GetAuthorizationToken”,
     “Resource”: “*”
   }
  ]
}

Then, the next policy is the resource-based policy at the image inside ECR. In order to provide push and pull action permissions, following permissions should be included in the ECR Image policy.

{
 “Version”: “2012–10–17”,
 “Statement”: [{
   “Sid”: “AllowPushPull”,
   “Effect”: “Allow”,
   “Principal”: {
     “AWS”: ["ARN-OF-IAM-USER"]
   },
  “Action”: [
   “ecr:BatchCheckLayerAvailability”,
   “ecr:BatchGetImage”,
   “ecr:CompleteLayerUpload”,
   “ecr:GetDownloadUrlForLayer”,
   “ecr:InitiateLayerUpload”,
   “ecr:PutImage”,
   “ecr:UploadLayerPart”
  ]
 }]
}

*** Replace the “ARN-OF-THE-IAM-USER” with the actual IAM user ARN which is configured in the AWS CLI. You can provide comma separated ARNs within double quotes into the same block above to provide access to more than one IAM user.

When all set, execute the command below to get a login to Amazon ECR for the IAM user.

aws --region us-east-1 ecr get-login-password | docker login --password-stdin --username AWS 111111111111.dkr.ecr.us-east-1.amazonaws.com

The above command is to get a login for Amazon ECR in us-east-1 region inside the account 111111111111 using AWS CLI Version 2. You may change the account ID and region as per your requirements.

Once this is executed successfully, you can perform usual push and pull commands to get your work done.

Pushing an image tagged as v0.1 to the my-repo container registry in account 111111111111 is as below.

docker push 111111111111.dkr.ecr.us-east-1.amazonaws.com/my-repo:v0.1

The following command can be used to pull the same image pushed above.

docker pull 111111111111.dkr.ecr.us-east-1.amazonaws.com/my-repo:v0.1

If you need to learn more about this, you can refer to the official documents from AWS which will give you more set of permissions too.

Conclusion

We discussed about why cross account access for Amazon ECR is important, where we may need it, and how we can grant access. In order to grant access, we used resource-based policy at Amazon ECR image. Further, we used an identity-based policy to grant permission to get an authorization token to access Amazon ECR for an IAM user. Apart from that, we discussed what is an identity-based policy and a resource-based policy in brief.