Improve security of zarf registry NodePort

[bburky]

Currently the zarf registry uses a NodePort which a) exposes an unneeded external listening port on every node and b) likely uses insecure communication between nodes.

Item a) can actually be mitigated today with the --nodeport-addresses=127.0.0.0/8 kube-proxy setting, but please note that this disables NodePorts entirely external to your nodes, this is not a solution for all users. However, if users do not need externally reachable NodePorts, this works today and disables the externally listening port.

One solution is to use a proper HTTPS registry, but this requires reconfiguring the CRI with the registry's likely-self-signed certificate. Today zarf is CRI agnostic and requires no manual configuration, perhaps this could be an alternate manual setting with the user manually reconfiguring their CRI, but I would like to see a secure configuration by default.

Another idea is to use a ClusterIP HTTPS registry and a DaemonSet reverse proxy pod listening on a 127.0.0.1:31999 hostPort (HTTP, localhost only). Zarf uses a localhost HTTP registry for zero configuration with the CRI which this would still support (and HTTP is not insecure on localhost). Communication between nodes would be secured with HTTPS.

(A hostPort is preferable to a hostNetwork here. It's least privilege, we don't want the permissions of the host network namespace. IT supports specifying hostIP: 127.0.0.1 so it will not be reachable externally, unlike NodePorts which depend on the --nodeport-addresses setting. It may be an issue that the hostPort will be inaccessible during registry restarts, a rolling restart like a NodePort supports is not possible. I'm also not sure what this startup will look like for new nodes without the DaemonSet pod yet on them and other things, needs some research.)

There are also a number of other in-cluster registries like https://github.com/XenitAB/spegel (which appears to be lighter weight than Dragonfly and Kraken). Spegel appears to do a very similar hostPort only binding as above, it's worth reviewing their configuration regardless. If we like one of these registries well enough to recommend we should test it, they should be compatible with zarf as an external registry and could be installed during zarf init, some minor work may be needed to bootstrap images.

[bburky]

See #375 about HA registries for some previous discussion of registries including some third party in-cluster registries.

[phillebaba]

@bburky a bit off topic from this issue but I am currently working on enabling other projects to use Spegel as a library instead. This would remove a lot of the security concerns connected to running Spegel in a container. The goal is to integrate Sepgel with k3s to enabled air gap installs. This might also be useful for zarf.