Let’s Talk Policy (for a Change)

While the American election season has focused much of the world’s attention directed to anything but a substantial discussion of policy, the Kubernetes networking community had other ideas. Back in July, Kubernetes 1.3 came out with support for network policies, making it the first of the container orchestrators to have such a capability built-in.

Currently, at beta level, the Kubernetes network policy API gives developers the ability to define rules that determine which pods (the Kubernetes term for a workload made up of one or more containers) can connect to which other pods. Think of it as a dynamic firewall around each microservice (but we’re not going to make Mexico pay for it).

You might think that, with several competing vendors being involved in the definition of the API, the work would have been bogged down by politics. Unlike in Washington, DC, however, the networking special interest group was a model of cooperation, focused on technical merits and clear end-user use cases. In fact, some of the vendors who worked on the specification are coming together for a panel at the upcoming CloudNativeCon — so think of this as a sneak peak into what might be discussed there.

Why Policy?

The first use case that many people come across is segmentation of the network into “tiers” (usually three) — for example, being able to specify that a back-end database tier can only be accessed from application tier pods, not directly from the front-end tier.

This, however, only scratches the surface of the network policy API. Its full power comes into play as developers embrace cloud-native application architectures, where dozens or hundreds of microservices communicate with one another, in a way that doesn’t neatly map to the traditional “three-tier” model.

In this case, the connectivity matrix is much more complex, and also dynamically changing as pods are created and destroyed. Network policy provides a way for developers to describe these more intricate relationships, in a language that is natural to them — but maps to powerful infrastructure-layer enforcement.

Network Policy: Part of the Cloud Native Security Picture

There has been a lot of talk about the security implications of the evolution to cloud-native application architectures. Kubernetes’ Network Policy API, and its implementations such as Project Calico, will be a critical element in addressing these concerns and enabling enterprises to meet strict compliance requirements.

Want to find out more?

For more detail on Kubernetes Network Policy, please see the longer version of this article in The New Stack.