Enable hostNetwork support in eck-operator Helm chart

[thbkrkr]

A PR has been opened to add hostNetworking support in eck-operator Helm chart: #6636.

After reading this istio/istio#38373 , in particular this comment:

I don't think this is secure, IMO, to run in host network. Adding it to the helm chart essentially means we are endorsing it.
If folks want to run insecure options to workaround broken CNIs/Kubernetes clusters, then they are free to do so (using things like https://docs.solo.io/gloo-edge/latest/installation/gateway/kubernetes/helm_advanced/, IstioOperator patching, etc), but I don't think we should officially endorse this.

I would like us to validate together the addition of this feature. I don't feel adding it to the helm chart means we endorse it. For me it's more about being as open as possible and letting people make their own choice.

[KrisJohnstone]

With all due respect to the guys at Istio I think they got it kinda wrong. If you have no firewall rules/security groups then you have other/bigger problems.

They also don't take into account that on large clusters exposing items on the hostNetwork is something some do for performance reasons (i.e. metrics).

Its up to the user to make sure they have mitigating controls, such as firewall/sg rules that only allow traffic on port 80/443 to workers/webservices. And that webhook ports aren't exposed publicly. And maybe that is what we should do (which is line with letting people make the choice) here, add a line to the values file or even readme making sure people are explicitly aware that they will need to make sure they have mitigating controls in place.

And lastly, their comments regarding using kustomize is nice, but tools such as argocd do not support using kustomize and helm.

Though now that I think about it, while the changes work for me in my use case, the port needs to be configurable in case people have other charts deployed that don't allow for the port to be configurable.

[thbkrkr]

We agreed to accept this change with the addition of a warning in comment.

Though now that I think about it, while the changes work for me in my use case, the port needs to be configurable in case people have other charts deployed that don't allow for the port to be configurable.

There may also be a problem as soon as you deploy the operator with several replicas which could end up on the same k8s node.

[KrisJohnstone]

Apologies for semi-disappearing, easter and then family stuff.

I've got some code committed locally however there appears to be a hard dependency on vault when trying to test locally.

make switch-kind bootstrap-k8s
/Library/Developer/CommandLineTools/usr/bin/make create-default-config
make[1]: Nothing to be done for `create-default-config'.
Error: VAULT_ADDR must be set
VAULT_ADDR must be set
make: *** [bootstrap-k8s] Error 1

Which I believe stems from L71 of kind.go. I don't have an instance of vault nor can I see any doco around how to set this up for local testing. Anyone able to assist please?

[thbkrkr]

Anyone able to assist please?

It's not great but you should be able to set VAULT_ADDR to anything as it shouldn't be used in your case.

[thbkrkr]

Closed by:

• Enable hostNetwork support in eck-operator Helm chart #6636
• Add operator flag to define webhook port #6691.