-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make "owners" field of source_ami_filter required: RFC #6584
Comments
👍 to this, absolutely. I encountered exactly this bug last week, ended up with a Monero miner instead of a vanilla Ubuntu AMI when the |
@007 Can you shoot me an email? I have a couple of questions about your experience with this issue. |
Done |
@SwampDragons I can't upgrade to Packer 1.3.0 because of this change. Essentially we use the same JSON Packer definitions for production AWS account as development AWS account, and only have to modify the The problem is the |
@nodesocket the "owners" field is a list, so I believe you should be able to simply provide both possible "owner" IDs and have the filter still work for both. Then no matter which (prod or dev) owner owns the AMI, you should be able to find one. |
Ahh, didn't realize |
Awesome! Super glad it isn't a blocker. |
You can also use We should probably add some more info in the docs. From the AWS docs:
https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html |
Good point. I've opened a PR updating docs: #6694 |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
HashiCorp's security team pointed out an interesting potential exploit where if you request an amazon AMI via a source_ami_filter, but don't have "owner" selected, you can accidentally use a malicious base image instead of one from your own organization or a trusted vendor.
The impact of making the "owner" field required would be low for the users (I strongly suspect that a majority of people using the filter already define the owner field) but could save users from making a potentially dangerous mistake. I think we should have Packer fail during validation with an error that says this field must be designated; if we decide that there is a valid use case where people may not want to have to set this field, we could potentially allow an opt out like setting "owner" to "any" but honestly I can't think of a situation where this really makes a great deal of sense.
I'm going to slate this for v1.3.0 but I'd like to hear community thoughts.
The text was updated successfully, but these errors were encountered: