Packer: Unencrypted -> Encrypted AMI Copy Step No Longer Works (or is necessary)

[farvour]

Packer seems to want to use the unencrypted -> encrypted snapshot methodology to create an encrypted AMI.

According to amazon now, it can be specified at launch.
https://aws.amazon.com/blogs/security/create-encrypted-amazon-ebs-volumes-custom-encryption-keys-launch-amazon-ec2-instance-2/

FOR BUGS:

Describe the problem and include the following information:

• Packer version from packer version: v1.3.1 (issue was seen in 1.2.x, which is why I upgraded)
• macOS High Sierra 10.13.6
• Debug log output from `PACKER_LOG=1 https://gist.github.com/farvour/84c21d6dffceac65b8da619921f7bd53

[azr]

Hello @farvour, 🙂

thanks for reporting this, looking at it ASAP.

[farvour]

Awesome. I worked around it by removing the encrypted true from my AMI block device mapping’s directive for sda1 but I think maybe packer should sanity check and not attempt to create the unencrypted AMI snapshot first if encrypt_root is true.

I ended up with the same end result as before so maybe the docs just need some clearer indication or packer just auto corrects itself.

On Sep 25, 2018, at 2:58 AM, Adrien Delorme [e-mail] wrote:

Hello @farvour, 🙂

thanks for reporting this, fixing it ASAP.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[nullify005]

👍 when the source volume is already encrypted the 'assume unencrypted to encrypted copy step' basically just adds time to the build & is entirely unnecessary

I'd love to disable encrypt_root, however it appears that when you set it to false & if the source volume is encrypted then things like AMI copy of the resulting encrypted AMI to another region fails since the flag is required in the go code to determine whether the destination AMI needs to be encrypted rather than looking at the AMI it's trying to copy & working it out that way.

https://github.com/hashicorp/packer/issues/6778

Is there a possibility of making packer a little more aware of whether the source volume is encrypted or not & then make the appropriate choices?

• if source is encrypted then the destination basically has to be encrypted regardless of whatever the user wants, therefore we can skip the additional copy unencrypted to encrypted step
• if the source is not encrypted then using the encrypt_boot flag is appropriate to allow the user to control whether the output should be encrypted
• if the output was encrypted (either because the source was encrypted or the encrypt_boot was true) then ALWAYS mark the destination for a region copy to be encrypted, rather than requiring encrypt_boot to be true as the marker for whether it needs to or not

[azr]

Hello, I will try first to see if we can omit passing the encryption parameter to preserve the current ami setting, otherwise since it's a bool and golang's default value for a bool is false, it will pass false when we try to get the 'default' behaviour.

AWS' doc says:

By default, CopyImage preserves the encryption status of source snapshots when creating destination copies. However, you can configure the parameters of the copy process to also encrypt the destination snapshots.

[azr]

Hey @farvour & @nullify005, I've tried to fix these issues in #6787; by having the encrypt param not be sent over when it's not set in packer's config.

Please tell me if that solves your problems.

packer_darwin_amd64.zip

packer_linux_amd64.zip

[farvour]

I am currently out of town for a week and a half yet but I'll give this a shot when I return. This PR may end up in the main line by then, but I'll try the point release here too.

[SwampDragons]

Bumped this to the 1.4.0 milestone because the solution could be backwards-incompatible in certain edge cases.

[aplsms]

Hello guys,
Any updates on it?

[rickard-von-essen]

When dealing with this also consider https://groups.google.com/d/msgid/packer-tool/ee19e981-65b7-4df8-9c99-8be1012d53ee%40googlegroups.com?utm_medium=email&utm_source=footer

If the boot is encrypted, all regions should default to the default EBS KMS key.

[azr]

@rickard-von-essen, the issue you linked should also be fixed by #6787, when copying to region(s), if you don't specify a key: a default one is picked.

[azr]

@aplsms or @farvour could you please tell me if the binary in #6787 fixes your issue ?

[azr]

Confirmed: https://github.com/hashicorp/packer/pull/6787#issuecomment-466531888 👍

[hashibot[bot]]

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.