Packer: Packer binds http server to 0.0.0.0

[LucidOne]

https://github.com/hashicorp/packer/blob/5fb6f69ad703981323072d6c9a860c49c5a6a419/common/step_http_server.go#L56

$ packer --version
1.2.5

[rickard-von-essen]

Yes.. Please explain what you think is wrong/could improved.

[LucidOne]

This is not ideal for the qemu builder, specifically making files such as preseed.cfg potentially available on the open internet. For the qemu builder it would be ideal to be able to bind this to 10.0.2.2 or 127.0.0.1 should also work. This is similar to the issue with #3533.

[arizvisa]

@LucidOne, is there some better way to determine the interface that the template can communicate with for all the builders? Or are you looking for just some configuration option to specify the address+port to bind to for the httpd?

[LucidOne]

OK, I think there are several approaches that are viable here. Some combination of them may be ideal.
1) Make the HTTP server address configurable.
2) Have the HTTP server return 403 forbidden for access from any IP other than the system being built. Perhaps a helper library that builders can call that sets the ACL for the http server.
3) Automatic iptables rule updates.
4) Warn that the HTTP server may be publicly accessible on the open internet.

I understand that some builders may need access across the open internet, but there are too many examples of things pressed/kickstart config files with passwords hardcoded.

[mwhooker]

@LucidOne Thanks for the ticket. I definitely see how binding to 0.0.0.0 could cause problems.

This is also a great list of ideas.

I understand that some builders may need access across the open internet

I don't know if that's the case. I'd want to double check, but I believe every time we start up the http server it's for a local hypervisor. Generally we don't expect the host running packer to have a public ip, so this wouldn't work across the open internet.

binding to 10.0.2.2 would be great, but would that work for every network configuration for every hypervisor?

I'd rather not make the address configurable if we can get away with a better solution. This seems like it would be easier to misconfigure than not. We generally like to solve this type of thing by giving higher level options, tied with intent, rather than the lower level details.

I like ideas 4 and 2. I think it's enough if we just add that we're listening on 0.0.0.0 to the Starting HTTP server on port %d log.

For #2, we'd have to know the IP address of the guest. After a brief look at the builders that use the http server, this seems possible. I hoped we could call GetHTTPAddr in common/step_http_server.go, but unfortunately that's only set afterwards, in StepTypeBootCommand. Happy to brainstorm ideas, but anyone enterprising enough should be able to get it working

[LucidOne]

I'm personally not a fan of #3 as getting it wrong could be painful. However, one idea would be to output what the iptable rules should be along with the warning in #4.

QEMU is assigning 10.0.2.2 via DHCP and I think you could get it to configure very differently if you bring up the VM network interface up without hostfwd. This could happen by using network hardware virtualization such as SR-IOV for the primary interface.

I'd argue if you don't want the user to have to configure .HTTPIP then the builder should be able to call SetHTTPAddr(), because it has the information to correctly configure the network. ex. checking "qemuargs" to see if hostfwd was used. It could fall back to "auto" and bind to 0.0.0.0 and throw a warning if it can't determine the correct network config.

[rickard-von-essen]

I don't know if that's the case. I'd want to double check, but I believe every time we start up the http server it's for a local hypervisor. Generally we don't expect the host running packer to have a public ip, so this wouldn't work across the open internet.

cloudstack is a counter example.

However, one idea would be to output what the iptable rules should be along with the warning in #4.

QEMU can run on many OS'es so that is only a partial fix. And I think we need one that covers all builders.

[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.