[ECS] [request]: Policies to ensure container image attestation

[mprencipe]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request ECS currently doesn't have a native, declarative mechanism to ensure only images signed with a certain key. The reference relies on running verification in a separate Lambda which adds complexity. It would be nice to define a clear, declarative policy in CDK/CloudFormation.

Which service(s) is this request for? ECS/Fargate

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Allow only images built and signed in a CI/CD pipeline (CodePipeline, GitHub Actions etc) can be run. This ensures unwanted code is not run.

Are you currently working around this issue? Reference solution can be used as a workaround.

Additional context AWS reference implementation: https://containersonaws.com/pattern/ecs-fargate-container-image-signing-and-verification k8s policy controller documentation: https://docs.sigstore.dev/policy-controller/overview/

Attachments None

[vibhav-ag]

@mprencipe couldn't you scope down ECS permissions (register-task-def, create-service, update-service, run-task) to your pipelines to achieve this outcome?

[mprencipe]

Can they be configured to only allow images signed e.g. by a service in an on-prem environment?

[acdha]

Here's an example of a scenario you might want to block: someone has permission to update task definitions but you don't want them to be able to add arbitrary containers because it might start with a xray/aws-xray-daemon sidecar but end up with other containers from sources you have no basis for trusting. There is an ecs:container-name IAM condition but that's restricting you to enumerating the sources you want to allow using IAM string operators and also requires you to audit every IAM policy to validate that the IAM condition(s) are correctly defined.

Obviously that's not impossible but it seems like it would be more robust from a security perspective if you could give ECS a list of trusted keys and be able to provably state that it's no longer possible to run code in that cluster unless it's been signed by one of those keys.