NCP - Network Policies

One of the features I really like with the NSX Container Plugin (NCP) is how easy it is to create Distributed Firewall Rules (DFW) at an NSX level using Kubernetes Network Policies. By adding these rules in your’e enabling microsegmentation, but implementing it with the application. This means you can get all the code driven goodness from your microsegmentation! Which in turn enables the velocity of application deployments not be slowed down through either security or network team bottlenecks, everyone is a winner.

So how does this work in practice? Assuming you’ve got NCP deployed and talking to NSX, this is nice and simple.

For this demonstration, I’ll be using the ACME Fitness demo app

Here you can see the page that is generated, the top row of images comes from the catalogue service & separate mongo database.

When I apply this policy to the resource, it should break the catalogue service as it will no longer be able to communicate with the database. There is a really good run down of the different options with a network policy object on the Kubernetes docs. This policy will:

• Apply to any pod with the label service=catalog-db
• Apply to ingress traffic only
• Allow ingress from pods with the label service=frontend to the port TCP/27017 (default mongo port)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: acme-catalog-netpol
  namespace: acme
spec:
  podSelector:
    matchLabels:
      service: catalog-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: frontend
    ports:
    - protocol: TCP
      port: 27017

This will then create a number of objects within NSX:

• Group with dynamic membership containing all ports on the logical switch created for the namespace
• A src & tgt IP Set with dynamic membership containing all ports associated with a pod matching the labels specified
• Rules to allow the traffic specified, near the top of the rule list
• Rules to drop all other traffic, near the the bottom of the rule list

The exact location & section the rules are created in will depend on the specific environment.

From a Kubernetes level, describing the network policies is really useful, describing in plain English what traffic is allowed.

kubectl describe networkpolicies acme-catalog-netpol --namespace acme

Name:         acme-catalog-netpol
Namespace:    acme
Created on:   2020-10-21 20:43:15 +0100 BST
Labels:       <none>
Annotations:  Spec:
  PodSelector:     service=catalog-db
  Allowing ingress traffic:
    To Port: 27017/TCP
    From:
      PodSelector: service=frontend
  Allowing egress traffic:
    To Port: <any> (traffic allowed to all ports)
    To: <any> (traffic not restricted by source)
  Policy Types: Ingress, Egress

You can now see the product images from the catalogue database are no longer present.

To enable this to work, we change the ingress selector to service=catalog and hey presto! This time the only service that can communicate with the database is the catalog service, reducing the possiblities of somebody gaining access to your images.

This was all done using a TKGI deployment, but the same principles will apply wherever the NSX Container Plugin is used.

Hopefully you can see the possibilities of this and how it can simplify bringing microsegmentation to your container workloads.