Skip to content
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

Add support for boot_mode option for Amazon EBS builder #465

Open
hegyre opened this issue Mar 5, 2024 · 6 comments
Open

Add support for boot_mode option for Amazon EBS builder #465

hegyre opened this issue Mar 5, 2024 · 6 comments
Labels
enhancement stage/waiting-on-upstream This issue is waiting on an upstream change

Comments

@hegyre
Copy link

hegyre commented Mar 5, 2024

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

Those PRs #131 and #340 add support for boot_mode, but only for the "Chroot" and "EBS Surrogate" builders.
I would need to be able to select the boot_mode also for "EBS" builder.

Use Case(s)

CIS hardening needs to disable vfat filesystem. However, as mentionned:

Disabling the vfat module can prevent boot on UEFI systems.

I'd like to test it out by creating an AMI while booting with Legacy-bios instead of UEFI.

Potential configuration

Same as documented on the EBS Surrogate builder documentation for boot_mode and optionnaly for uefi_data.
Valid options should be legacy-bios and uefi + the non-mentionned uefi-preferred from #362.

Potential References

@lorengordon
Copy link
Contributor

Note that the EBS builder uses the CreateImage API, which does not offer any option to set the BootMode. Instead, when using CreateImage, the BootMode will be inherited from the source instance.

The chroot and ebssurrogate builders use RegisterImage, which does support the BootMode option.

@hegyre
Copy link
Author

hegyre commented Mar 5, 2024

Hello,
It's not for creating the image itself but for running the temporary EC2 instance.

@lorengordon
Copy link
Contributor

lorengordon commented Mar 5, 2024

Ahh, the BootMode is inherited from the selected source image. You cannot set it in the RunInstances API.

You can force BIOS mode by using a UEFI Preferred image, and selecting an older instance type, say an m4, that does not support Nitro (required for UEFI).

@hegyre
Copy link
Author

hegyre commented Mar 5, 2024

Ah indeed that's unfortunate but we cannot force the boot mode on instance launch. It's always derived from the AMI.

The drawback is that we cannot test Legacy-bios on Nitro unless we copy an original AMI first and set the boot_mode, only then we can select it with Packer.

Anyway, I'll live with that. Thanks a lot for your quick reply here !

@lorengordon
Copy link
Contributor

lorengordon commented Mar 5, 2024

Yeah, the API support for BootMode is very limited. None of CreateImage, CopyImage, or RunInstances support setting the Boot Mode. It can only be set by RegisterImage. If you have access to paid AWS Support, it would probably be worth opening a feature request to enhance the API support for BootMode.

@lbajolet-hashicorp lbajolet-hashicorp added the stage/waiting-on-upstream This issue is waiting on an upstream change label Mar 28, 2024
@lbajolet-hashicorp
Copy link
Contributor

Hi @hegyre and @lorengordon,

Thanks for the discussion already here, and sorry we haven't pinged here sooner.

This looks like we can't do much on the plugin side for now, I'll leave the issue open to keep an eye on this topic, hopefully we'll have some flexibility some day to change the boot mode (though I presume this is tied to the AMI for a reason, partitioning/boot loading is very different between the two modes unfortunately).
If/when it becomes an option to run instances with a different boot mode, we can update this topic!

In the meantime regarding your use case @hegyre, I believe you may be able to workaround that limitation by creating a BIOS-compatible image for Centos using the ebssurrogate builder, and use that image as the base for what you're trying to achieve? Would that work for you?

Also looking at the CIS Hardening page you've linked, it looks like this is removed from a newer version of the guidelines? Is this still something you need to do for compliance?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stage/waiting-on-upstream This issue is waiting on an upstream change
Projects
None yet
Development

No branches or pull requests

3 participants