Network Isolation and Policy Specification in Kubernetes

/net.alpha.kubernetes.io/v1alpha1/namespace/default/networkpolicys/ ``` Third party network controllers can now listen on these endpoints and react as necessary when resources are created, modified or deleted. _Note: With the upcoming release of Kubernetes 1.3 - when the Network Policy API is released in beta form - there will be no need to create a ThirdPartyResource API endpoint as shown above._  Network isolation is off by default so that all pods can communicate as they normally do. However, it’s important to know that once network isolation is enabled, all traffic to all pods, in all namespaces is blocked, which means that enabling isolation is going to change the behavior of your pods Network isolation is enabled by defining the _network-isolation_ annotation on namespaces as shown below: ``` net.alpha.kubernetes.io/network-isolation: [on | off] ``` Once network isolation is enabled, explicit network policies **must be applied** to enable pod communication. A policy specification can be applied to a namespace to define the details of the policy as shown below: ``` POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/ { "kind": "NetworkPolicy", "metadata": { "name": "pol1" }, "spec": { "allowIncoming": { "from": [ { "pods": { "segment": "frontend" } } ], "toPorts": [ { "port": 80, "protocol": "TCP" } ] }, "podSelector": { "segment": "backend" } } } ``` In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1** ’ applied as indicated. Specifically, pods with the **segment** label ‘ **backend** ’ would allow TCP traffic on port 80 from pods with the **segment** label ‘ **frontend** ’ to be received. Today, Romana, OpenShift, OpenContrail and Calico support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).  **How does it work?** Each solution has their their own specific implementation details. Today, they rely on some kind of on-host enforcement mechanism, but future implementations could also be built that apply policy on a hypervisor, or even directly by the network itself.  External policy control software (specifics vary across implementations) will watch the new API endpoint for pods being created and/or new policies being applied. When an event occurs that requires policy configuration, the listener will recognize the change and a controller will respond by configuring the interface and applying the policy.  The diagram below shows an API listener and policy controller responding to updates by applying a network policy locally via a host agent. The network interface on the pods is configured by a CNI plugin on the host (not shown).

Third-party network controllers can listen on API endpoints and react to resource changes. Network isolation is off by default, but once enabled, all traffic is blocked and explicit network policies must be applied. A policy specification defines policy details, such as allowing TCP traffic on port 80 from frontend pods to backend pods. Romana, OpenShift, OpenContrail, and Calico support network policies, with Cisco and VMware working on implementations. These solutions rely on on-host enforcement, but future implementations could apply policy on a hypervisor or directly by the network. External policy control software watches the API endpoint for pod creation and policy application events, and a controller configures the interface and applies the policy.