How-To: Basic network security implementation for Kubernetes Clusters with NetworkPolicy examples
Welcome to my Kubernetes how-to series, where I intend to breakdown and showcase the how-tos and the gotchas of the Kubernetes configuration.
If you’re here, you are aware that the POD-to-POD communication on the [any] Kubernetes Cluster is available to all namespaces and all PODs, — It’s free for all.
Irrespective if you are using VPC native subnet, or your Kubernetes comes with its own internal IP subnet.
The main limiting of such Pod-to-Pod communications being the end-Container port-configuration itself.
Otherwise, as itis lacking any container-specific header whitelisting, you are able to telnet/netcat to other Pod’s ports without any restrictions or limitations.
This may be permitted for the dev cluster, but unacceptable security stance in any respectable Production Kubernetes Cluster environment.
It is worth to note that while Kubernetes cluster does come with the cluster-native networking — IP-aliases which persist on the larger Google Cloud Network and ARE subject to The Cloud Platform Firewall rules, there is little granularity offered to manage the nuances of application-to-application communication given the ephemeral nature of the POD(s) IPs.
The Default option offered and should be pursued in the form of Network Policies at the relevant GKE Cluster level.
The difference between Firewall Rule and a NetworkPolicy
Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)
There are NetworkPolicy “Firewall” Direction and Selectors
There are two types of traffic direction you can apply restrictive policies on, alongside two selectors you can employ to select particular pods or namespace
- Egress — The traffic leaving the designated PODs (with podSelector) or NAMESPACESs (with namespaceSelector)
- Ingress — The traffic reaching the designated PODs (with podSelector) or NAMESPACESs (with namespaceSelector)
The Snippet of Tag-based “Firewall” NetworkPolicy
- This will, by default, BLACKLIST any access into the POD from any other POD within that cluster.
- This will, as specified, will whitelist all-ports all-access, from the namespace: api-proxy to PODs which has a label app: redis where the latter could be in any other namespace.
More Granular NetworkPolicy Controls
You are able to define both Ingress and Egress rules in one NetworkPolicy definition, as well as have a degree of granularity as to which PORTS such applications are to be permitted to access.
- from:  # only accessible from the ALL on port 80
- port: 80
- port: 6973
- port: 53
Right, That is pretty much it.
Hope you enjoyed this. Enjoying the read?
👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.