Packer: Encrypted EBS conflict error from AWS
We run packer nightly to generate new AMIs for our ECS cluster instances as the first step in a patch management strategy we have for keeping our ECS instances up to date. Recently (10/16/2018), the job began failing despite no changes being made to our template or code. The error is:
Error creating AMI: InvalidBlockDeviceMapping: the encrypted flag cannot be specified since device /dev/xvda has a conflicting encryption setting.
It seems like perhaps AWS has changed something in their API to reject the request that packer is making. When I did a debug step through, it appeared that the only conflicting setting was that the volume was already encrypted. I don't think this is a misconfiguration on our side since this seems to be a fairly textbook use packer for encrypting an EBS volume.
Packer Version: Packer v1.3.1
Host platform: CentOS Linux release 7.3.1611 (Core)
Debug Log Gist: https://gist.github.com/rysch242/883f2b5d2e230e962c1530c7ca5c83fb
Template gist: https://gist.github.com/rysch242/0272ac25352b6e0b138bd629e3f46e26
rysch242
All 9 comments
Hello @rysch242, thanks for reporting, this should be fixed by #6787; which we have planned for version 1.4.0.
If you decide to use that branch; you should not pass any encryption setting as the volume is already encrypted; encryption setting will remain.
In then meantime you can probably use a build of packer from that branch. I will try to keep the branch up to date with master.
Related: #6778 #6762
azr
on 22 Oct 2018
I'm not sure I follow your suggestion. I'm basing my packer build on an AMI with an unencrypted root volume (Amazon Linux ECS Optimized) and adding a new encrypted ECS volume. If I were to not pass any encryption setting for either the root or the additional ECS volume, it'd result in an unencrypted volume in my AMI, which is what I'm trying to avoid. Could you give me an example template doing what you're suggesting?
rysch242
on 22 Oct 2018
@azr I have the same issue described here and please let me know if there is any fix or a new build I could verify the fix.
Thank you!
WeekendsBull
on 22 Oct 2018
Here is a build of packer on that fix branch :
packer_darwin_amd64.zip
packer_linux_amd64.zip
packer_windows_amd64.zip
@rysch242; the error message I see is :
the encrypted flag cannot be specified since device /dev/xvda has a conflicting encryption setting.
This new build of packer allows to not set the encryption setting, so that we keep whatever was set.
Now your problem is different; you would like to encrypt that unencrypted drive.
Let me run some tests to see what I can do.
azr
on 23 Oct 2018
Okay, so going around in the aws console and booting machines, it turns out /dev/xvda is the root drive, and you cannot set it to encrypted this way.
Screenshot booting an amazon-ecs-optimized image from aws.amazon.com :
When you set "encrypt_boot": true then the boot drive /dev/xvda will be encrypted in the resulting ami and you wont need to set ami_block_device_mappings for /dev/xvda
Screenshot booting an ami resulting from an amazon-ecs-optimized with "encrypt_boot": true:
So a correct resolution would be to just remove the ami_block_device_mappings setting from the build file. 馃檪
Recently aws has been doing some changes in that area so it might be why it stopped working.
azr
on 23 Oct 2018
Ahh, this makes sense, thank you for researching it so thoroughly. As you say, the issue was that I was specifying encrypt_boot as well as explicitly specifying that the root volume be encrypted with ami_block_device_mappings. The confusion on my part was due to inheriting this packer config from someone else and believing that the ami_block_device_mappings was how we were attaching a second EBS volume to the AMI during build when in fact the ECS Optimized AMI already includes the second EBS volume. Removing the ami_block_device_mappings section entirely as you suggested allowed packer to build correctly and create an AMI with both volumes encrypted. Thanks so much for the effort and sorry for the errant bug report!
rysch242
on 24 Oct 2018
No problemo 馃檪
azr
on 25 Oct 2018
how does one create an image with boot and a second volume encrypted when the source image only has one volume (boot)?
frank3427
on 17 Dec 2018
Hello @frank3427, you have to set the ami_block_device_mappings.
I recommend asking questions in packer's mailing list
Also some good reads:
https://www.packer.io/docs/builders/amazon-ebs.html#ami_block_device_mappings
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html
azr
on 17 Dec 2018
Related issues
DanielBo
路
3Comments
mushon4
路
3Comments
Nikoos
路
3Comments
mvermaes
路
3Comments
tleyden
路
3Comments
Most helpful comment
Ahh, this makes sense, thank you for researching it so thoroughly. As you say, the issue was that I was specifying
encrypt_bootas well as explicitly specifying that the root volume be encrypted withami_block_device_mappings. The confusion on my part was due to inheriting this packer config from someone else and believing that theami_block_device_mappingswas how we were attaching a second EBS volume to the AMI during build when in fact the ECS Optimized AMI already includes the second EBS volume. Removing theami_block_device_mappingssection entirely as you suggested allowed packer to build correctly and create an AMI with both volumes encrypted. Thanks so much for the effort and sorry for the errant bug report!