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.
Description
Currently when pushing to an AWS ECR repo, with the exception of passing profile, there is no way to assume a role as part of the ECR login process. This is useful in scenarios where packer configs are source controlled and used in a team environment. Relying on the profile attribute assumes all packer clients are configured with the same AWS profile config. In many AWS environments, roles are assumed as part of workflows rather than creating a local profiles and passing profile information. In Terraform we are able to assume roles to build assets in multiple AWS accounts depending the situation. Additionally If you want to push to multiple ECR repos at once, the greater the importance of aws profiles matching across all packer clients when source controlled.
I would like to see if it's possible to include the support the use of assume role directive when logging into ECR repos similar to how Terraform aws provider can assume roles.
Use Case(s)
We manage 28 distinct AWS accounts and we have a use case where we may need to push the same image to multiple ECR repos as part of the build process. When sharing the packer configs in github, anywhere packer builds are ran either must use the specific profile name. This results in either all packer clients needing to have their aws cli configured using the same profile names or when packer is ran, the user must proactively update the profile based on their unique machine. Allowing the use of role_arns similar to terraform will allow clients to use the packer files independent of their local machine configuration.
If packer is ran from a central AWS account to push to another, that EC2 instance needs to have aws profiles configured locally instead of using the attached role and assuming the proper role when needed. If packer is ran from containers, the containers must have their aws profiles configured instead of using instance profiles default configuration.
Please search the existing issues for relevant feature requests, and use the reaction feature (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to add upvotes to pre-existing requests.
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.
Description
Currently when pushing to an AWS ECR repo, with the exception of passing profile, there is no way to assume a role as part of the ECR login process. This is useful in scenarios where packer configs are source controlled and used in a team environment. Relying on the profile attribute assumes all packer clients are configured with the same AWS profile config. In many AWS environments, roles are assumed as part of workflows rather than creating a local profiles and passing profile information. In Terraform we are able to assume roles to build assets in multiple AWS accounts depending the situation. Additionally If you want to push to multiple ECR repos at once, the greater the importance of aws profiles matching across all packer clients when source controlled.
I would like to see if it's possible to include the support the use of assume role directive when logging into ECR repos similar to how Terraform aws provider can assume roles.
Use Case(s)
We manage 28 distinct AWS accounts and we have a use case where we may need to push the same image to multiple ECR repos as part of the build process. When sharing the packer configs in github, anywhere packer builds are ran either must use the specific profile name. This results in either all packer clients needing to have their aws cli configured using the same profile names or when packer is ran, the user must proactively update the profile based on their unique machine. Allowing the use of role_arns similar to terraform will allow clients to use the packer files independent of their local machine configuration.
If packer is ran from a central AWS account to push to another, that EC2 instance needs to have aws profiles configured locally instead of using the attached role and assuming the proper role when needed. If packer is ran from containers, the containers must have their aws profiles configured instead of using instance profiles default configuration.
Potential configuration