Move networkpolicies out of /contrib into /common (#2385)

[rawc0der]

Which issue is resolved by this Pull Request: Resolves #2385

Description of your changes: Moved networkpolicies from /contrib to /common and added the base overlay to the example kustomization.

Checklist:

• [ ] Unit tests pass: Make sure you have installed kustomize == ^5.0.0
  1. make generate-changed-only
  2. make test

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[juliusvonkohout]

can you add @TobiasGoerke as additional reviewer (not approver) in the owners file?

[juliusvonkohout]

/LGTM

[juliusvonkohout]

@rawc0der why did you disable seldon? Seldon will still be used in Kubeflow 1.9.

[rawc0der]

I was actually thinking that /contrib components network policies should maybe be moved into their corresponding /contrib application folder path and only enabled by default in /common/networkpolicies/ if the component is required. Otherwise we end up having some unnecessary netpols for optional components.

I can enable it back as maybe there is no problem by running this netpol by default.

What's you view on this?

[juliusvonkohout]

Kserve is aslo in /contrib but installed by default. Seldon is also quite popular. So having them in one place for the time being is what i prefer. @kimwnasptd what do you think?

[rawc0der]

TO conclude, one example of where Istio AuthPolicies lacks some support is with services using protocol specific implementation, i.e. the databases: mysql, rds.

AuthorizationPolicy can only cover HTTP/gRPC based protocols at the moment.

Advantages of securing with Network policies:

• allows to be universal on all application that use IP
• allows applying policies to DNS, SQL databases, real-time streaming, other types of services

Without netpols:

• The Istio’s proxy is based on Envoy, which is implemented as a user space daemon
• Istio policy enforcement happens inside pod sidecar in the same network namespace.
• Due to some pods getting access to CAP_NET_ADMIN, services can be compromised and proxy could be bypassed

Attack vector in Layer 7:

Attacking unprotected pods
Attempting to deny service to protected pods by sending lots of traffic
Exfiltrating data collected in the pod
Attacking the cluster infrastructure (servers or Kubernetes services)
Attacking services outside the mesh, like databases, storage arrays, or legacy systems.

Last take:

 Istio and Network Policy have different strengths in applying policy. Istio is application-protocol aware and highly flexible, making it ideal for applying policy in support of operational goals, like service routing, retries, circuit-breaking, etc, and for security that operates at the application layer, such as token validation. Network Policy is universal, highly efficient, and isolated from the pods, making it ideal for applying policy in support of network security goals

From this blog post.

[juliusvonkohout]

@rawc0der

"rawc0der User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted. " I think you have to remove yourself from the owners list or become approved by google.

I now have the power to merge this https://github.com/kubeflow/internal-acls/pull/584#event-11061599883 , but i need to discuss this with Kimonas first.

[juliusvonkohout]

@rawcoder please fix the merge conflict and i think you have to remove yourself from the owners list or become approved by google. Otherwise i have to fork this before merging.

[juliusvonkohout]

/hold

[juliusvonkohout]

@andreyvelich can you take this up with the KSC ?

[juliusvonkohout]

@terrytangyuan can you take this up with the KSC ?

[terrytangyuan]

I think this is in our agenda but we haven't got to it yet. cc @kubeflow/kubeflow-steering-committee

[rimolive]

@juliusvonkohout Do we have KSC approval for merging this?

[juliusvonkohout]

I think the KSC still has to decide, but i provided most arguments in the community call, so i hope it is just a formal approval.

[jbottum]

I am +1 considering @juliusvonkohout says this is not breaking change. It is in line with a security profile strategy goals and helps to unblock a CNCF requirement for graduation. By default it will be turned on with this change. It can be disabled by commenting out one line. Can we get feedback from distributions ? @kimwnasptd @james-jwu @johnugeorge others?

[juliusvonkohout]

As discussed in the community call with three KSC members we will merge it now.

/lgtm /approve

Thank you for moving enabling it by default @rawcoder.

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: juliusvonkohout, rawc0der

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [juliusvonkohout]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[juliusvonkohout]

/unhold