ECR assets: security implications of central repository

[eladb]

Originally posted by @skorfmann in #5733 (comment)

I'm wondering what this means for IAM permissions. Here's an example which we're using at the moment:

    const taskDefinition = new ecs.FargateTaskDefinition(this, 'FooDefinition', {
      memoryLimitMiB: 2048,
      cpu: 1024    
    });

    const asset = new DockerImageAsset(this, 'FooEcrImage', {
      directory: path.join(__dirname, 'assets'),
    });
    
    asset.repository.grantPull(taskDefinition.taskRole)

(snippet from here https://gist.github.com/skorfmann/8da4eb64845e10f5937655520d53ac14#file-docker-image-asset-ts-L13-L22)

If I understand this change correctly, each principal which is granted access to the central ECR repository (aws-cdk/assets), will be able to pull all images. How's that aligned with the principle of minimal privilege?

[eladb]

@skorfmann you are correct. Currently ECR doesn't support granular permissions, which implies that anyone who has access to the ECR repository can pull any image. Indeed, this is not ideal in terms of least privilege.

I'd like to understand your use case for isolation better. Generally speaking, since IAM permissions within an account are managed at the principal level, we have an assumption that applications that run within the same AWS environment cannot be strictly isolated from each other. Any principal (role/user/group) created in this account can theoretically have a policy that allows it to pull all images from all ECR repositories.

Our recommended practice is that if you have a need for security isolation between apps, they should probably be deployed into different environments (either within the same AWS Organization or not). Then, each one of these applications will have its own ECR repository.

Having said that, we are aware that teams have different needs and constraints and I'd like to understand more about your security use case so we can think if there is something we can do to help.

[skorfmann]

@eladb Thanks for extracting this as a separate issue 👍

Any principal (role/user/group) created in this account can theoretically have a policy that allows it to pull all images from all ECR repositories.

Yes, I'm aware that this is the case. For the case where we need strict isolation, we do use separate accounts.

The current use-case we have for the ecr assets package is a Step Functions workflow which includes a few Fargate tasks. There's no requirement for strict isolation in this context, but it'd be nice to have.

My original comment was more addressing my concern, that the switch to a central docker image repository is conflicting with the least privileges principle by default and leaves no path open to have stricter permissions if you'd want or require them.

[eladb]

@skorfmann thanks for the inputs and letting us know this is not a strict requirement for your use case.

Our new design for the bootstrapping (which is part of the CI/CD story) will allow users to customize where images are pushed (the default will be a central repo through). This means that if someone has a use case for stricter permissions, they will be able to implement it and won't be blocked by the framework.

When ECR will support image-level permissions, we will be able to tighten these policies automatically.

Closing for now.

[fabianluque]

Our new design for the bootstrapping (which is part of the CI/CD story) will allow users to customize where images are pushed (the default will be a central repo through). This means that if someone has a use case for stricter permissions, they will be able to implement it and won't be blocked by the framework.

@eladb Can you elaborate a little bit more about what kind of customization that would be? Any documentation available?