Port of Calico GlobalNetworkPolicy

[josh.f...@gmail.com]

I didn’t find this in a quick search but are there plans to bring Calico’s Global Network Policy into the core API similar to what’s been done with NetworkPolicy?

[Tim Hockin]

There are no "plans" but not because anyone is against it, per se.
Mostly because it has not been proposed. If this is a pain point
people are feeling, we need a volunteer to start by documenting the
perceived requirements. I don't think "just take what Calico did" is
going to fly, but it may well be that this API captures the right
requirements. We need to start at the beginning.

On Tue, Jun 25, 2019 at 6:25 AM <josh.f...@gmail.com> wrote:
>
> I didn’t find this in a quick search but are there plans to bring Calico’s Global Network Policy into the core API similar to what’s been done with NetworkPolicy?
>

> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-sig-network.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/b6c9f405-6091-4a10-9014-7ffb99a786a8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[josh.f...@gmail.com]

For myself the only requirements have been to apply default deny for egress traffic across all namespaces, log those denies(which isn’t a function of NetworkPolicies supports now). We have additional global policies that then allow egress to the Kubernetes API service or the kube-system namespace.

[Thomas Graf]

On Fri, 28 Jun 2019 at 09:03, <josh.f...@gmail.com> wrote:
>
> For myself the only requirements have been to apply default deny for egress traffic across all namespaces, log those denies(which isn’t a function of NetworkPolicies supports now). We have additional global policies that then allow egress to the Kubernetes API service or the kube-system namespace.

We've had similar discussions with users. In the case of CIlium, we
chose to implement the global default deny with an agent flag to avoid
solving the race condition that the policy must be loaded before the
first workload is scheduled onto the cluster.

The main discussions we had with users regarding the potential
introduction of global policy is visibility. While RBAC may provide a
user with access to a particular namespace which has NetworkPolicy
loaded, it can lead to confusion if additional policies are in scope
which are not visible to that user for any communication within that
namespace.

[Tim Hockin]

We have had customers ask for similar things, but nobody has tackled a
design yet.

> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-sig-network.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CACby%3Dp%3DmVwdbbNOG4RdvTg%2BC6cypuZ-%2BYuPsHrG9LWdJ42jPhg%40mail.gmail.com.

[josh.f...@gmail.com]

Is there an outline somewhere of what design methodology or requirements need to be used?

[Tim Hockin]

No. I think a simple doc that proposes use-cases and a SWAG at
priorities is the starting place. Clearly folks like Calico have done
that, so maybe understanding their API choices makes sense.

On Tue, Jul 2, 2019 at 6:00 AM <josh.f...@gmail.com> wrote:
>
> Is there an outline somewhere of what design methodology or requirements need to be used?
>

> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-sig-network.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/a80c99cc-f4f5-45b3-ae7c-afa625fd0f6c%40googlegroups.com.