Kubernetes -Security for Network architect

How do you manage security for Kubernetes? It’s a difficult question for DevOps, but it’s more difficult for network architect.

If you check online there are a ton of resources which guide you through the best practice -e.g. Hardening your cluster’s security. And as the time goes by, some best practice is ended up being built into as a default -e.g. RBAC is default access control for GKE1.8 or higher.

Kubernetes is composed of a few component, and each of them interact densely. And to make the pod communication smooth, it expects all pods to communicate without NAT via overlay network. In my opinion, the biggest challenge in Kubernetes is network. It’s one of my favourite part how elegantly Kubernetes utilises external modules. You would have multiple options how you deploy overlay network, some of them are really simple like old dot1q tagging, while the other uses VXLAN, BGP, GRE. Because of this variations, there is no so-called best practice for Kubernetes overlay network security.

The Network Policy might be able to use to restrict the communication between certain pods. However, you need to predefine those communication and it’s usually not the best option. From DevOps perspective, historically this kind of network security has been done by network architect, and the same structure should be applied here.

I have consulted and deployed a numbers of clusters in GCP/AWS and on-premise. And it can be quite straight forward if you know how you approach. Contact me to get an insight.