Support hostNetwork: true configuration for kubewarden-controller and policy-server in Helm chart

[Nikita130520]

Is your feature request related to a problem?

Hi Kubewarden team,

We are using Kubewarden in a restricted Kubernetes environment where webhook communication must go through the host network interface. Because of this, we require hostNetwork: true to be set on the following components:

kubewarden-controller

policy-server (e.g. policy-server-default)

If hostNetwork is not enabled, we encounter the following webhook error when trying to apply policies like disallow-service-loadbalancer:

Error from server (InternalError): error when creating "test.yaml": Internal error occurred: failed calling webhook "clusterwide-disallow-service-loadbalancer.kubew arden.admission": failed to call webhook: Post "https://policy-server-default.kubewarden.svc:443/validate/clusterwide-disallow-service-loadbalancer?timeout=10s": Ad dress is not allowed

Currently, the official Helm charts do not provide any configuration options to enable hostNetwork, so we are forced to manually patch the deployments after installation.

The same error we encountered with kubewarden-controller but as of now we updated deployment file to use hostnetwork manually and it worked.

Solution you'd like

Please add support in the Helm charts to configure hostNetwork for:

kubewarden-controller
policy-server

This could be done by adding a hostNetwork field in values.yaml and wiring it in the deployment templates like:

spec:
template:
spec:
hostNetwork: {{ .Values.hostNetwork | default false }}

This would let users enable it like this:

hostNetwork: true

Alternatives you've considered

No response

Anything else?

No response

[flavio]

Doing the the changes to the helm charts would not be enough, since the Policy Server deployments are reconciled by the controller. Hence we would need to change the controller code to create a deployment that makes use of hostnetwork.

Giving host network access to the policy server and the controllers is making the whole deployment less secure:

• the processes running inside of the pods have visibility of all the network interfaces of the node
• the webhook endpoints are exposed also outside of the cluster

This increases the attack surface and is not needed. I'm against doing such a change.

Finally, I think you would also have issues with the certificates used to secure the webhook endpoints, since they are bound to the internal services.

This is the first time we run into such a requirement, can you elaborate a bit more on the reasons of this architecture?

[flavio]

Closing, please reopen when you have the answers I made

[MichaelGerhart]

@flavio I can't re-open this issue because I didn't create it (Please let me know if you can re-open, or I should just create a fresh issue), but we are trying to migrate from gatekeeper to Kubewarden and are having the same issue with the inability to set hostNetwork to true on the admission controller deployment.

This is the first time we run into such a requirement, can you elaborate a bit more on the reasons of this architecture?

To answer your question on why this requirement can occur, the organization I work for leverages AWS EKS at large scale (Many hundreds of clusters). We provision each of these clusters in a /23 of private routable address space which results in a scenario where we cannot use AWS VPC CNI without running out of routable IP space.

As a solution, we leverage a third party CNI (That AWS also does support the usage of) that does NAT on every worker node in the cluster instead of binding upwards of 64 routable IPs to a single EC2 depending on the instance type.

Because we are no longer using the native CNI to resolve this problem, the EKS Managed Control plane no longer has network access to admission controller endpoints, thusly any admission controller the EKS API may need to talk to has to be set with hostNetwork: True.

Hopefully this helps define a clear use case for this functionality and let me know if you have any additional questions.

[viccuad]

Reopened, This is valid. Thanks for the background information.