-
Notifications
You must be signed in to change notification settings - Fork 118
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
introduction of custom iPXE firmware support #429
Conversation
/test-ubuntu-integration-main |
/hold |
/test-centos-integration-main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nits
/test-ubuntu-integration-main |
3 similar comments
/test-ubuntu-integration-main |
/test-ubuntu-integration-main |
/test-ubuntu-integration-main |
/hold cancel |
/cc @lentzi90 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work from what I can understand. I must confess this is a bit outside of my expertise though
/test-ubuntu-integration-main |
</VirtualHost> | ||
|
||
<Location ~ "^/grub.*/"> | ||
SSLRequireSSL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Why not just everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a few things in mind when I have done this
- I want to use the modular functionality of the Apache config files, so config files that are related to a type of boot interface should only restrict files that are also related to the same Ironic boot interface/boot method.
- The other thing is that, at the moment firmware loading is not secured by TLS only the image download this I will explain in detail under your other comments.
# Client is PXE booting over EFI without iPXE ROM; send EFI version of iPXE chainloader | ||
# Client is PXE booting over EFI without iPXE ROM; send EFI version of iPXE chainloader do the same also if iPXE ROM boots but TLS is enabled | ||
{%- if env.IPXE_TLS_SETUP == "true" %} | ||
dhcp-boot=tag:efi,tag:ipxe,snponly.efi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not look right. You're saying "if iPXE on UEFI, boot iPXE".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal here is to always force the chain loading of our iPXE firmware and not whatever is running on the machine by default. Our firmware will have the ability to exit this loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so it will only work for your custom firmware? :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes because the firmware has to contain the correct certificate, although by default iPXE supports the Mozzilla cert bundle but in our case we have our own for Ironic.
I could add https address support for loading the boot.ipxe directly but then that would exclude all machines that doesn't have a TLS enabled IPXE with the Mozzilla bundle because I can't enable the two addresses at the same time because the dhcp "tag:"s have to match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have looked into the possibility to differentiate our custom firmware from a regular TLS enabled iPXE via a custom dhcp tag but I have not found any documented ways to do it . I am not sure in general whether a custom DHCP tag is a thing or not.
@@ -29,13 +29,23 @@ dhcp-option=option{% if ":" in env["DNS_IP"] %}6{% endif %}:dns-server,{{ env["D | |||
# IPv4 Configuration: | |||
dhcp-match=ipxe,175 | |||
# Client is already running iPXE; move to next stage of chainloading | |||
{%- if env.IPXE_TLS_SETUP == "true" %} | |||
# iPXE with (U)EFI | |||
dhcp-boot=tag:efi,tag:ipxe,http://{{ env.IRONIC_URL_HOST }}:{{ env.HTTP_PORT }}/custom-ipxe/snponly.efi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"http://" here sorta defeats the whole point.. if the attacker can intersect the connection, they can provide a different image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right this will load the firmware via http, at the moment the TLS support is only introduced for the later part of the chain loading .There are a simple reason for this, we don't know what will be running on a machine by default, it could be and iPXE firmware that is unable to use https and first we need to provide a firmware that we can use with TLS.
The topic of man in the middle during firmware loading is very important I agree but that will be a followup feature based on all the things that are getting introduced in the ipxe-builder image and here. Securing the firmware loading won't be as easy as turning on TLS as I have mentioned we don't know what the host machine is capable at the initial stage of the loading. I plan to go into the direction of "trusted firmware" which would mean that we would only allow a firmware to get to our images if it can identify itself as a trusted image.
@@ -0,0 +1,81 @@ | |||
#!ipxe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know Ironic allows copying this file, but I'd much rather prefer we don't do it. You're going to miss any upstream fixes, and reconciling will be very hard. Can we add the missing functionality in Ironic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to get this in first, but for sure I can later implement changes from the Ironic side also I agree eventually a natively supported approach should be the way to do it.
4c62c59
to
00e3478
Compare
This commit adds the following: - Support for detecting iPXE certificates - When iPXE certs are detected, the iPXE services and configs will be advertised with https addresses - Enforce chainloading of the iPXE firmware provided by the user even if the client machine comes with an iPXE firmware by default - Adds modular iPXE apache2 config file to enable separate iPXE specific virtual host (port) where TLS is enforced - Custom iPXE config file template has been added thus Ironic can generate node specific iPXE config files that use the custom iPXE firmware - A set of environment variable that control the new iPXE related features Signed-off-by: Adam Rozman <adam.rozman@est.tech>
/test-ubuntu-integration-main |
1 similar comment
/test-ubuntu-integration-main |
/test-centos-integration-main |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: elfosardo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold |
@lentzi90 could you please lgtm this? it has the "hold" only because we are not sure this should go in the first ironic-image release or not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/hold cancel |
OCPBUGS-23903: Ironic side of external_http_url (METAL-163) is not wired in correctly
This PR adds the following, :
This PR builds on top of #428 so it will be on hold until that is merged.
IPXE building functionality was originally planned to be hosted in this repository but after extensive community discussion I have decided to move the iPXE firmware builder to it's own repository.