(aws-codepipeline-actions): TagParameterContainerImage unusable cross-account #15070

danwiltshire · 2021-06-10T15:34:56Z

Using TagParameterContainerImage as a property for a stack in a different account causes a resolution error.

Reproduction Steps

const myPipeline = new MyPipeline(app, 'my-pipeline', {
  env: nonprod
}

new MyFargateApp(app, 'my-app', {
  env: prod
  image: myPipeline.tagParameterContainerImage
}

What did you expect to happen?

Stack my-app should reference the ECR repo from my-pipeline.

What actually happened?

Error: Resolution error: Resolution error: Resolution error: Resolution error: Resolution error: Cannot use resource 'my-app/FargateService/TaskDef/ExecutionRole' in a cross-environment fashion, the resource's physical name must be explicit set or use 'PhysicalName.GENERATE_IF_NEEDED'.

Environment

CDK CLI Version : 1.107.0 (build 52c4434)
Framework Version: 1.107.0
Node.js Version: 14.16.0
OS : WSL2 Ubuntu 20.04.02 LTS on Windows 10 1909
Language (Version): TypeScript (3.9.9)

Other details

I'm using ApplicationLoadBalancedFargateService.

This is 🐛 Bug Report

The text was updated successfully, but these errors were encountered:

skinny85 · 2021-06-10T17:33:54Z

Thanks for reporting @danwiltshire. Confirming I was able to reproduce it. I'm working on a fix.

In the meantime, you should be able to unblock yourself by passing the executionRole of the TaskDefinition explicitly with a Role that has the name set, like so:

      const fargateTaskDefinition = new ecs.FargateTaskDefinition(this, 'ServiceTaskDefinition', {
        executionRole: new iam.Role(serviceStack, 'ExecutionRole', {
          assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
          roleName: 'my-name',
        }),
      });

If you don't want to set a name yourself, you can pass roleName as cdk.PhysicalName.GENERATE_IF_NEEDED, and the CDK will generate it for you automatically.

When TagParameterContainerImage is used from a different acocunt than the service itself is in, it fails resolution, because the Task's execution Role does not have a physical name set by default. Create it with PhysicalName.GENERATE_IF_NEEDED, so that it assigns a name when accessed from a cross-account context. Fixes aws#15070

danwiltshire · 2021-06-11T08:07:40Z

Hey @skinny85 thanks, this got me a bit further. I'm now getting another issue where the ECR policy principal is not valid.

Error: Invalid parameter at 'PolicyText' failed to satisfy constraint: 'Invalid repository policy provided'

Cause: The Principal field must contain an asterisk when a full role ARN is used.

Solutions:

Use an asterisk in the ARN
Use the AWS root reference (as shown in Working policy below).

Synthed CFN:

    "FargatePipelineEcsDeployRepository70287658": {
      "Type": "AWS::ECR::Repository",
      "Properties": {
        "RepositoryName": "<EXPLICIT_REPO_NAME>",
        "RepositoryPolicyText": {
          "Statement": [
            {
              "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
              ],
              "Effect": "Allow",
              "Principal": {
                "AWS": {
                  "Fn::Join": [
                    "",
                    [
                      "arn:",
                      {
                        "Ref": "AWS::Partition"
                      },
                      ":iam::<ACCOUNT_NUMBER>:role/prod-appappexecutionrole0e3f44e5e1548be0860e"
                    ]
                  ]
                }
              }
            }
          ],
          "Version": "2012-10-17"
        },
      },
      "UpdateReplacePolicy": "Retain",
      "DeletionPolicy": "Retain",
      "Metadata": {
        "aws:cdk:path": ".../FargatePipeline/EcsDeployRepository/Resource"
      }
    },

Working policy:

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "new statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_NUMBER>:root"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ]
    }
  ]
}

Other notes:

The ECR permission GUI also states an asterisk is needed: Statement[0].Principal must match the following: "/\*/" @ Statement[0].Principal
I've unblocked myself by using an escape hatch.

Workaround

        const cfnRepository = appEcrRepo.node.defaultChild as ecr.CfnRepository;

        cfnRepository.repositoryPolicyText = {
            "Version": "2008-10-17",
            "Statement": [
              {
                "Effect": "Allow",
                "Principal": {
                  "AWS": "arn:aws:iam::<ACCOUNT_NUMBER>:root"
                },
                "Action": [
                  "ecr:BatchCheckLayerAvailability",
                  "ecr:BatchGetImage",
                  "ecr:GetDownloadUrlForLayer"
                ]
              }
            ]
          }

If you need this in a new issue I'm happy to spin one up.

skinny85 · 2021-06-11T15:11:36Z

Hmm, but the error you get and the resolution don't match each other...?

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "new statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_NUMBER>:root"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ]
    }
  ]
}

This does not contain a * in the Principal of the Statement...?

danwiltshire · 2021-06-11T15:26:35Z

Correct, that seems to be the second available solution.

If you were to take a role ARN and put an asterisk in, that works to.

skinny85 · 2021-06-11T18:41:14Z

But an asterisk where? 🤔 Just tack it on randomly at the end of the Role ARN?

danwiltshire · 2021-06-14T11:44:55Z

Yeah pretty much. I wonder if ECR just doesn't allow granting access to roles? Looking at the AWS docs granting a role isn't listed: https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html

…15073) When TagParameterContainerImage is used from a different acocunt than the service itself is in, it fails resolution, because the Task's execution Role does not have a physical name set by default. Create it with PhysicalName.GENERATE_IF_NEEDED, so that it assigns a name when accessed from a cross-account context. Fixes #15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

github-actions · 2021-06-15T01:52:03Z

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

skinny85 · 2021-07-13T01:10:16Z

@danwiltshire confirming I was able to reproduce this error. I'm working on a fix.

skinny85 · 2021-07-13T01:38:49Z

I can confirm just adding a * at the end of the Role ARN does not solve the problem.

skinny85 · 2021-07-13T19:04:19Z

Hmm, so I think I know what the problem is.

The issue is that, when using TagParameterContainerImage across accounts, the execution Role of the Task in the Stack is added to the resource policy of the ECR Repository. However, that Role doesn't exist at the time the Repository is deployed! (Because it belongs to the service Stack which will only be deployed by the Pipeline) And apparently ECR validates that.

skinny85 · 2021-07-13T19:11:29Z

If you provide a Role that does exist in the Repository's resource policy, the deployment is successful. So ECR definitely does support Role-based resource policies.

danwiltshire · 2021-07-13T19:11:41Z

Yeah you're right, I just tried specifying a nonexistent role in a different account and it failed. As soon as I specify a role that exists, it works.

skinny85 · 2021-07-13T19:13:49Z

This is quite the conundrum. Not sure exactly how to handle this from the CDK side.

danwiltshire · 2021-07-13T19:16:06Z

There is the option of granting access at the account level e.g. arn:aws:iam::01234567890:root... although maybe not ideal for the security concious.

…ws#15073) When TagParameterContainerImage is used from a different acocunt than the service itself is in, it fails resolution, because the Task's execution Role does not have a physical name set by default. Create it with PhysicalName.GENERATE_IF_NEEDED, so that it assigns a name when accessed from a cross-account context. Fixes aws#15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ments When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes aws#15070

…ments (#16376) When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes #15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

github-actions · 2022-12-09T07:26:59Z

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

…ments (aws#16376) When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes aws#15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

danwiltshire added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jun 10, 2021

github-actions bot added the @aws-cdk/aws-codepipeline-actions label Jun 10, 2021

github-actions bot assigned skinny85 Jun 10, 2021

skinny85 added effort/small Small work item – less than a day of effort p1 and removed needs-triage This issue or PR still needs to be triaged. labels Jun 10, 2021

skinny85 mentioned this issue Jun 10, 2021

fix(ecs): TagParameterContainerImage cannot be used across accounts #15073

Merged

mergify bot closed this as completed in #15073 Jun 15, 2021

skinny85 reopened this Jun 18, 2021

skinny85 mentioned this issue Sep 4, 2021

fix(ecr): grants for cross-account principals result in failed deployments #16376

Merged

kartickvijayakumar mentioned this issue Nov 18, 2021

(aws-codepipeline-actions): Support cross-account ECS deployments with codepipeline actions #17558

Closed

skinny85 added the in-progress This issue is being actively worked on. label May 4, 2022

skinny85 removed their assignment May 4, 2022

mergify bot closed this as completed in #16376 Dec 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

(aws-codepipeline-actions): TagParameterContainerImage unusable cross-account #15070

(aws-codepipeline-actions): TagParameterContainerImage unusable cross-account #15070

danwiltshire commented Jun 10, 2021 •

edited

Loading

skinny85 commented Jun 10, 2021

danwiltshire commented Jun 11, 2021 •

edited

Loading

skinny85 commented Jun 11, 2021

danwiltshire commented Jun 11, 2021

skinny85 commented Jun 11, 2021

danwiltshire commented Jun 14, 2021

github-actions bot commented Jun 15, 2021

skinny85 commented Jul 13, 2021

skinny85 commented Jul 13, 2021

skinny85 commented Jul 13, 2021 •

edited

Loading

skinny85 commented Jul 13, 2021 •

edited

Loading

danwiltshire commented Jul 13, 2021

skinny85 commented Jul 13, 2021

danwiltshire commented Jul 13, 2021

github-actions bot commented Dec 9, 2022

(aws-codepipeline-actions): TagParameterContainerImage unusable cross-account #15070

(aws-codepipeline-actions): TagParameterContainerImage unusable cross-account #15070

Comments

danwiltshire commented Jun 10, 2021 • edited Loading

Reproduction Steps

What did you expect to happen?

What actually happened?

Environment

Other details

skinny85 commented Jun 10, 2021

danwiltshire commented Jun 11, 2021 • edited Loading

skinny85 commented Jun 11, 2021

danwiltshire commented Jun 11, 2021

skinny85 commented Jun 11, 2021

danwiltshire commented Jun 14, 2021

github-actions bot commented Jun 15, 2021

⚠️COMMENT VISIBILITY WARNING⚠️

skinny85 commented Jul 13, 2021

skinny85 commented Jul 13, 2021

skinny85 commented Jul 13, 2021 • edited Loading

skinny85 commented Jul 13, 2021 • edited Loading

danwiltshire commented Jul 13, 2021

skinny85 commented Jul 13, 2021

danwiltshire commented Jul 13, 2021

github-actions bot commented Dec 9, 2022

⚠️COMMENT VISIBILITY WARNING⚠️

danwiltshire commented Jun 10, 2021 •

edited

Loading

danwiltshire commented Jun 11, 2021 •

edited

Loading

skinny85 commented Jul 13, 2021 •

edited

Loading

skinny85 commented Jul 13, 2021 •

edited

Loading