Incorrect config validation prevents use of the most efficent build behaviour.
Suppose you want to:
Create an encrypted AMI...
... and do so most efficiently, by using launch_block_device_mappings to launch the build instance encrypted initially, rather than performing a copy/encrypt operation to apply encryption after building an unencrypted AMI first...
... but you also want the final AMI to be copied to other regions using specified keys
The plugin rejects such a configuration with the message:
If you have set either region_kms_key_ids or kms_key_id, encrypt_boot must also be true.
If you have a custom kms key you'd like to apply to the launch volume, and are only building in one region, it is more efficient to leave this and encrypt_boot empty and to instead set the key id in the launch_block_device_mappings (you can find an example below). This saves potentially many minutes at the end of the build by preventing Packer from having to copy and re-encrypt the image at the end of the build.
Just because I've specified region_kms_key_ids to customize the keys to be used for the copy to ami_regions, shouldn't prevent me from using this build technique.
Overview of the Issue / Reproduction steps
Incorrect config validation prevents use of the most efficent build behaviour.
Suppose you want to:
launch_block_device_mappings
to launch the build instance encrypted initially, rather than performing a copy/encrypt operation to apply encryption after building an unencrypted AMI first...The plugin rejects such a configuration with the message:
I don't think this is correct. The technique of encrypting via
launch_block_device_mappings
is documented at https://developer.hashicorp.com/packer/integrations/hashicorp/amazon/latest/components/builder/ebs within the documentation forkms_key_id
:Just because I've specified
region_kms_key_ids
to customize the keys to be used for the copy toami_regions
, shouldn't prevent me from using this build technique.Simplified Packer Buildfile