How can I get my ECS Fargate cluster to pull a container from a private Docker registry that is in another AWS account? If the private Docker registry is in the same account I don't need authentication but I get CannotPullContainerError: Error response from daemon: pull access denied for <account id>.dkr.ecr.ap-southeast-2.amazonaws.com/project/container, repository does not exist or may require 'docker login'
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html talks about authentication and private registries but doesn't seem to mention my use case of an ECR in another AWS account. It looks like I can add access to a defined list of AWS accounts in the ECR permissions but possibly there are other approaches? The passwords that generated for ECR only seem to last for 12 hours so that won't work.
In the account running your fargate service the task execution role specified in your task definition should have permissions to pull an image.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:eu-west-1:<account id>:repository/project",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
]}
And in the account containing the ECR you should specify in ecr policy that the account containing the task execution role is allowed to access the repository. In the ecr policy below the whole account is added which might be a bit much security wise but that something you can tighten.
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "PullImage",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<accountid>:root"
},
"Action": [
"ecr:BatchGetImage",
"ecr:DescribeImages",
"ecr:DescribeRepositories",
"ecr:GetDownloadUrlForLayer",
"ecr:GetLifecyclePolicy",
"ecr:GetLifecyclePolicyPreview",
"ecr:GetRepositoryPolicy",
"ecr:ListImages"
]
}
]
}
Related
I am trying to create an IAM ecsInstanceRole for an ECS cluster with container instances. I am hitting a brick wall as follows:
I created a IAM role named ecsInstanceRole.
The trust relationship is:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
The attached policy is the AWS managed AmazonEC2ContainerServiceforEC2Role.
I think that everything was done by the book. Yet, when I try to attach the IAM role in the Create Cluster, the above role does not appear as an option. Same happens when i just try to create a simple EC2 instance. Role does not appear. Should I not be able to see the role since the trusted entity is ec2.amazonaws.com.
Please help. This is really driving me nuts.
Thanks.
Theodoros
you have created iam role for EC2 instance rather than for ECS service and hence you are not able to lookup the role while creating the ECS cluster.
you need to create role for ECS service & choose "EC2 Role for Elastic Container Service", that will have following in-line policy which provides required permissions to EC2 instances in ECS to access ECS
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeTags",
"ecs:CreateCluster",
"ecs:DeregisterContainerInstance",
"ecs:DiscoverPollEndpoint",
"ecs:Poll",
"ecs:RegisterContainerInstance",
"ecs:StartTelemetrySession",
"ecs:UpdateContainerInstancesState",
"ecs:Submit*",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
After that you need to add the trust relationship for the above role as mentioned in the following documentation.
https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/instance_IAM_role.html
I want to upload to S3 from a Fargate task. Can this be achieved by only specifying a ExecutionRoleArn as opposed to specifying a both a ExecutionRoleArn and a TaskRoleArn?
If I specify a ExecutionRoleArn that has the following Permission Policies attached:
Custom policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
AmazonECSTaskExecutionRolePolicy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
With the following trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"lambda.amazonaws.com",
"ecs-tasks.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
Would this be sufficient to allow the task to upload to S3? Or do I need to define a TaskRoleArn?
The ExecutionRoleArn is used by the service to setup the task correctly, this includes pulling any images down from ECR.
The TaskRoleArn is used by the task to give it the permissions it needs to interact with other AWS Services (such as S3).
Technically both Arns could be the same, however I would suggest separating them to be different roles to avoid confusion over the permissions required for both of the scenarios the role is used for.
Additionally you should have the endpoint for ecs.amazonaws.com. In fact the full list of services depending on how you're using ECS are below (although most could be removed such as spot if you're not using spot, or autoscaling if you're not using autoscaling).
"ecs.amazonaws.com",
"ecs-tasks.amazonaws.com",
"spot.amazonaws.com",
"spotfleet.amazonaws.com",
"ecs.application-autoscaling.amazonaws.com",
"autoscaling.amazonaws.com"
In the case of Fargate, both IAM role pay different role
Execution Role
This is role is mandatory and you can not run the task without this role even if you add ExecuationRole policy in Task Role
To produce this error just set Execution role =None, you will not able to launch the task.
AWS Forums (Unable to create a new revision of Task Definition)
Task Role
This role is optional and you can add s3 related permission in this role,
Optional IAM role that tasks can use to make API requests to authorized AWS services.
Your police seems okay,
Create ecs_s3_upload_role
Add below policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
Now Fargate Task will able to upload to S3 bucket.
Your policies don't include any s3 related permissions. Thus you should define your s3 permissions in a task role:
With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task.
I'm trying to build a docker image from a Pipeline account and push it into the ECR of another account (Dev).
While I'm able to docker push from codebuild to an ECR repo within the same account (Pipeline), I'm having difficulty doing this for an external AWS account ECR.
The policy attached to the ECR repo on the Dev account:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPush",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<pipelineAccountID>:role/service-role/<codebuildRole>"
},
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:CompleteLayerUpload",
"ecr:GetDownloadUrlForLayer",
"ecr:InitiateLayerUpload",
"ecr:PutImage",
"ecr:UploadLayerPart"
]
}
]
}
On my pipeline account, the service role running the build project matches the ARN on the policy above, and my buildspec contains the following snippet that pushes the image:
- $(aws ecr get-login --no-include-email --region us-east-1 --registry-ids <DevAccount>)
- docker tag <imageName>:latest $ECR_REPO_DEV:latest
- docker push $ECR_REPO_DEV:latest
Codebuild is able to log into ECR successfully, but when it tries to actually push the image, I get:
*denied: User: arn:aws:sts::<pipelineAccountID>:assumed-role/<codebuildRole>/AWSCodeBuild-413cfca0-133a-4f37-b505-a94668201e26 is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-1:<DevAccount>:repository/<repo>*
Additionally, I've gone ahead and made sure that the IAM policy for role (residing on the codepipeline account) has permissions for this repo:
{
"Sid": "CrossAccountRepo",
"Effect": "Allow",
"Action": "ecr:*",
"Resource": "arn:aws:ecr:us-east-1:<DevAccount>:repository/sg-api"
}
I have little idea now on what I could be missing. The only thing that comes to mind is having the build run with a cross-account role but I'm not even sure that's possible. My goal is to have the build pipeline separate from the dev. account as I hear that's best practice.
Suggestions?
Thanks in advance.
Based on my understanding of this and the error message above, the most common cause is that the ECR repository does not have a policy which would allow the CodeBuild IAM role to access it.
Please set this policy on the ECR Repo:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPush",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<dev acount>:root"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability",
"ecr:PutImage",
"ecr:InitiateLayerUpload",
"ecr:UploadLayerPart",
"ecr:CompleteLayerUpload"
]
}
]
}
Ref: https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html#IAM_allow_other_accounts
Please add this policy on the CodeBuild service role:
{
"Sid": "CrossAccountRepo",
"Effect": "Allow",
"Action": "ecr:*",
"Resource": "*"
}
I am implementing CodePipeline; using GitHub, CodeBuild and Amazon ECS (blue/green). The role I am using, is the one generated by the Pipeline: ecsTaskExecutionRole
When generated, it is equipped with the following policies:
AmazonECSTaskExecutionRolePolicy (containing the following actions):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]}
And the following Trust relationships:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"codebuild.amazonaws.com",
"ecs-tasks.amazonaws.com",
]
},
"Action": "sts:AssumeRole"
}
]
}
Given that the role is auto-generated, one would assume that either it would have ALL the necessary permissions (for the pipeline to function) OR AWS would have a guide on which permissions to assign (to either a policy OR the trust relationship configuration).
Despite, updating the trust relationship to include:
"Service": [
"codebuild.amazonaws.com",
"ecs-tasks.amazonaws.com",
"ec2.amazonaws.com",
"codedeploy.amazonaws.com",
"codepipeline.amazonaws.com",
"s3.amazonaws.com"
]
I still get the error:
I have seen this issue raised in multiple blogs/forum, spanning the past 1-2 years; it's incredible that this is still not properly documented as part of the AWS tutorials (or relative blogs).
"The provided role does not have sufficient permissions to access CodeDeploy"
This error suggests the CodePipeline role is missing "codedeploy:" related permissions.
Can you please add
codedeploy:*
to the role and try again.
If you do not want to add all CodeDeploy permissions, you will need to investigate 'AccessDenied' calls in Cloudtrail and allow just those. Usually these are the required ones:
{
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetApplicationRevision",
"codedeploy:GetApplication",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:RegisterApplicationRevision"
],
"Resource": "*",
"Effect": "Allow"
},
The default "CodePipeline Service Role Policy" is documented here:
[1] Manage the CodePipeline Service Role - Review the Default CodePipeline Service Role Policy - https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-custom-role.html#view-default-service-role-policy
I'm trying to follow the steps to use amazon elastic container registry (ECR) but I'm stuck at the first step, which is obtaining an auth token.
Command:
aws ecr get-login
Or...
aws ecr get-login --region=us-west-2
Error:
An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:iam::9#####4:user/### is not authorized to perform: ecr:GetAuthorizationToken on resource: *
AWS Permissions on user for region us-west-2:
AmazonEC2FullAccess
AmazonEC2ContainerRegistryFullAccess
Billing
AdministratorAccess
AmazonECS_FullAccess
AWS CLI version:
aws help --version
aws-cli/1.14.40 Python/3.6.4 Darwin/18.2.0 botocore/1.8.44
Please note that you're not allowing your user any access to ECR in a sense.
Try adding the following policy to the user:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:DescribeImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}]
}
https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr_managed_policies.html#AmazonEC2ContainerRegistryReadOnly
As general advice, ecr:GetAuthorizationToken must apparently be applied to all resources * but all other ECR permissions can be scoped. When setting up ECR permissions as below, that user/role can login into Docker via CLI and still only access those images that user/role is supposed to.
Example with scoped permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability",
"ecr:CompleteLayerUpload",
"ecr:GetDownloadUrlForLayer",
"ecr:InitiateLayerUpload",
"ecr:PutImage",
"ecr:UploadLayerPart"
],
"Resource": "arn:aws:ecr:${region}:${account}:repository/${repo-name}"
},
{
"Effect": "Allow",
"Action": "ecr:GetAuthorizationToken",
"Resource": "*"
}
]
}
From my observations, scoping ecr:GetAuthorizationToken to any ECR repositories will result in AccessDeniedException.