Add More Flexible Network Policies to Namespaces

[marwinski]

I like the default NetworkPolicy switch for karydia, however I believe it is too static.

I can currently think of two policies to add when a namespace is created:

1. block the metadata service
2. block the host network

This resolves quite some possible vulnerabilities, however this might be too strict and some pods might want to opt out of this (e.g. get access to the metadata service and/or the hosts).

[CodeClinch]

Currently, there is only one network policy available, which blocks all egress traffic. I think this feature should be extended in the following way:

Add more pre-defined network policies so that a user can choose the best fit for his requirements. And it should also be possible that a user can create a custom network policy if the defaults are not fitting.

The following network policies should be provided:

Level 1)

• Block metadata service
• Block access to kube-system namespace
• Block access to the host network

Level 2)

• Level 1
• Block internet access (egress)

Level 3)

• Level 2
• Permit pod to pod communication only within a namespace (block all communication between pods of different namespaces)

Level 4

• Custom network policies

By default, the level 2 network policy will be created whenever a namespace is created. This default should be specified in the KarydiaSecurityPolicy and can be overwritten with an annotation on a selected namespace.

@marwinski would be great if you could give feedback.

[CodeClinch]

Kubernetes NetworkPolicy does not provide a way to prevent outgoing connections from pods. However, Calico does.

It is hardly possible to block: 1) Block metadata service 2) Block access to kube-system namespace

[alban]

This calico doc seems outdated (v2.0). Kubernetes network policies now work both on ingress and egress

The egress policies seems to have been added in Kubernetes 1.8, after the ingress policies.

Gardener makes use of egress network policies (example for the api server)

[Neumann-Nils]

I added a three-level approach that implements the proposed functionality:

• karydia-network-policy-l1.yaml
• karydia-network-policy-l2.yaml
• karydia-network-policy-l3.yaml

Before merging the new network-policies, we need to:

• [x] Label the kube-system namespace when starting Karydia (or use the label gardener.cloud/purpose: kube-system - as this label is Gardener-specific, we should probably not use it for compatibility reasons)
• [x] Add integration tests for each level
• [x] Update the documentation accordingly