Closed tzumainn closed 4 months ago
Check with @jtriley on his workaround.
The workaround I've been using is instead of assigning a floating IP directly to a particular host, setup a floating IP port forward per port you want to expose on the host instead. Example:
$ openstack floating ip port forwarding create \
--port <baremetal-host-port> \
--internal-protocol-port <port> \
--external-protocol-port <external-port> \
--internal-ip-address <baremetal-host-ip> \
--protocol tcp <floating-ip>
This also has the added benefit that the external port can be different from the internal so we can, for example, expose SSH on a non-standard port easily without needing to reconfigure the host, e.g.:
$ openstack floating ip port forwarding create \
--port <baremetal-host-port> \
--internal-protocol-port 22 \
--external-protocol-port 2222 \
--internal-ip-address <baremetal-host-ip> \
--protocol tcp <floating-ip>
Looks like it'll be easier to document this port forwarding; notably, I now realize this is what MOCA does as well. I'll rename this task.
Apparently security groups don't work with bare metal instances:
https://lists.openstack.org/pipermail/openstack-discuss/2019-June/007100.html
This can be worked around since private networks have limited access and individual servers exposed to the public internet can be secured locally. However, the linked thread suggests that Neutron's firewall-as-a-service is also a viable solution, and may be preferable.
This is currently not enabled in the MOC ESI; it's probably best to wait until we have a staging environment to test this out.