How-To: Basic network security implementation for Kubernetes Clusters with NetworkPolicy examples

JPantsjoha
Oct 21, 2020 · 4 min read
Image for post
Image for post

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.

Image for post
Image for post

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

...
ingress:
- from:
- namespaceSelector:
matchLabels:
app: api-proxy
- podSelector:
matchLabels:
app: redis
...
  • 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.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-netpolicy
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
- Egress

ingress:
- from: [] # only accessible from the ALL on port 80
ports:
- port: 80
protocol: TCP

egress:
- to:
- podSelector:
matchLabels:
app: redis
ports:
- port: 6973
protocol: TCP
- to:
- namespaceSelector:
matchLabels:
name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- port: 53
protocol: UDP

Right, That is pretty much it.

Image for post
Image for post

Hope you enjoyed this. Enjoying the read?

Image for post
Image for post

👋 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.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

Image for post
Image for post

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts

Sign up for FAUN

By FAUN

Medium’s largest and most followed independent DevOps publication. Join thousands of aspiring developers and DevOps enthusiasts Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

JPantsjoha

Written by

All About engineering efficient infrastructure solutions by day and An Equity and The Blockchain investor by night.

FAUN

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

JPantsjoha

Written by

All About engineering efficient infrastructure solutions by day and An Equity and The Blockchain investor by night.

FAUN

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store