[Request]: the Jinja variable to get the environment AWS account ID

[xeres]

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 Multi-account support is now available. Thank you for your hard work. I have tried using the sample template bundle (fargate-service).

SEE ALSO: aws-sample/aws-proton-sample-templates@main/loadbalanced-fargate-svc

AWS Proton creates the CloudFormation stack for the service in the management account if I'm not misunderstanding. This stack includes the ECR repository.

So, I push some Dockerfile to the repository; Fargate cannot pull a new image from the ECR repository.

However, the ECR repository does not have a resource policy to allow access from the environment account. Therefore, I probably have no way to get the environment AWS account ID in pipeline_infrastructure.

SEE ALSO: Infrastructure template file parameters - AWS Proton Environment account connections - AWS Proton To solve this problem, I believe we need a variable in the Jinja template to get the environment AWS account ID to create resource policies.

Are you currently working around this issue? Although I haven't tried it yet, setting resource policies in ECR outside of AWS Proton's control.

[rafavallina]

Hi @xeres the CloudFormation stack for the environment and each individual service instance all goes into the environment account, not in the management account. The only thing that's in the management account is the Proton resource itself (e.g. the environment resource or the service resource). No CFN stacks in the management account in this case. Can you check if you have a different experience? If not, I'll close this issue as I think this is working.

[xeres]

Hi, @rafavallina.

Hi @xeres the CloudFormation stack for the environment and each individual service instance all goes into the environment account, not in the management account. The only thing that's in the management account is the Proton resource itself (e.g. the environment resource or the service resource).

In my case, it looks like the following.

The management account:

AWSProton-<service>-cloudformation--<random letters> (This includes the ECR repository)

The environment Account:

AWSProton-<service>-<service instance>-cloudformation--<random letters> (This includes task definitions and the ECR service)

It succeeds right after the service instance is created. However, when the user updates the Dockerfile, the CI/CD pipeline runs the build and fails.

Because the ECR service can't pull an image from the management account, and the ECR repository does not allow cross account access by resource policies.

In this way, we needed the the environment AWS account ID in pipeline_infrastructure, and the administrator must implements cross account resource policies.

If this is trouble, should I contact AWS support? AWS Proton has already GA, haha.

[rafavallina]

Hi @xeres I somehow missed this. Yeah, this is a miss on our side, we didn't build this properly. If you look at the sample templates we offer, we currently ask developers to provide the account ID as part of the pipeline input, but I agree with you that the right way to go is to include the account ID as a Jinja variable. Strangely enough, I was just discussing that with the team right before I came here!

I'm going to add this to the roadmap and will look to prioritize it as I think we need to update it quickly. Thanks for pointing it out!

[rafavallina]

This is live now. I don't have a what's new post about this, but I will point to it when available

@xeres I know you have been waiting for this for a while. Give it a try!