NetworkPolicies and Microsegmentation

Introduction

Kubernetes introduced NetworkPolicies in 1.6 and in OpenShift this feature was made GA in 3.7. Microsegmentation is the idea of protecting each host with host-specific firewall rules.

In this blog post, we will examine approaches for using NetworkPolicies to implement microsegmentation.

NetworkPolicy SDN

OpenShift installation requires you to choose the SDN implementation that is best for you. In OpenShift, available options include Subnet, Multitenant, and NetworkPolicy.

The network policy SDN features are a superset of the subnet and multitenant SDN features, making it an obvious choice for newly-built OpenShift clusters.

By default, NetworkPolicy SDN behaves like Subnet SDN, since there is no NetworkPolicy configured. If you want to recreate the multitenant SDN behavior, you need to add the following NetworkPolicy to each project:

kind: NetworkPolicy

apiVersion: extensions/v1beta1

metadata:

  name: allow-same-and-default-namespace

spec:

  ingress:

  - from:

    - podSelector: {}

  - from:

    - namespaceSelector:

        matchLabels:

          name: default

This NetworkPolicy says that pods in this namespace can accept connections from other pods in the same namespace and from the default namespace (to allow for the router connections).

You also need to label the default project as follows:

oc label namespace default name=default

The creation of this NetworkPolicy object can be automated by editing the OpenShift project template. You can do this during installation by adding the following configuration to your Ansible inventory file:

openshift_project_request_template_edits:

  - key: objects

    action: append

    value:

      kind: NetworkPolicy

      apiVersion: extensions/v1beta1

      metadata:

        name: allow-same-and-default-namespace

        ...

NetworkPolicy Implementation

In OpenShift, NetworkPolicies are implemented as OVS flow rules. NetworkPolicies flow rules are created in table 80. With this command (which you are required to run on one of the SDN nodes) you can view the flow rules corresponding to the defined NetworkPolicies:

ovs-ofctl dump-flows -O OpenFlow13 br0 | grep 80

For example, if you define a NetworkPolicy as follows:

kind: NetworkPolicy

apiVersion: extensions/v1beta1

metadata:

  name: prova

spec:

  podSelector:

    matchLabels:

      app: product-catalog

  ingress:

  - ports:

    - protocol: TCP

      port: 8080

and have a pod that is selected by this NetworkPolicy, the output will be something like this:

cookie=0x0, duration=249.002s, table=80, n_packets=0, n_bytes=0, priority=150,tcp,reg1=0x6d285,nw_dst=10.128.0.67,tp_dst=8080 actions=output:NXM_NX_REG2[]

cookie=0x0, duration=248.994s, table=80, n_packets=0, n_bytes=0, priority=100,ip,reg1=0x6d285,nw_dst=10.128.0.67 actions=drop

where 10.128.0.67 was the address of the pod.

NetworkPolicy Object Ownership

NetworkPolicy objects need to be owned by a team. Possible owners are the application development team, the OpenShift ops team, or the security team. Ultimately, the security team has the mandate to ensure that the NetworkPolicy objects are created correctly regardless of who manages them. Often times a security organization creates security policy documents that other teams in the company need to comply with. These documents will shape how NetworkPolicy objects are created.

Because of the declarative nature of the NetworkPolicies API, it is possible to create tools that work at a higher level of abstraction. With these tools, we can describe the company security policies, and in turn, the tools will derive the NetworkPolicy objects for each deployed application.

These tools will be responsible for continuously ensuring that the correct NetworkPolicy objects are defined. Kubernetes Controllers can be one way to make sure that the actual state matches the desired state. This idea of continuously monitoring the security controls is also known as ongoing security assessments.

Network Zones and Fine-Grained Firewall Rules

In traditional data centers, we usually find coarse-grained network security zones. Each network security zone is isolated from the others with carefully scrutinized and manually configured firewall rules. Traffic within a single zone normally flows freely.

A common set up is a three-tier network with a Demilitarized Zone (DMZ), an internal network, and a data network (in increasing degree of protection). It is not uncommon for large enterprises to have more than three network zones.

Because manual intervention in the firewall rule configuration is necessary, each organization has to strike a balance between security, which calls for smaller, more numerous network security zones, and the cost of maintaining those zones.

Software Defined Networks (SDNs) change this landscape. In fact, with SDN, firewall rule configurations can be easily automated, decreasing the cost of network operations. With SDNs, it is now conceivable to define per-host firewall rules. This concept is also known as microsegmentation.

NetworkPolicies represent firewall rules in the Kubernetes/OpenShift SDN and can be used to achieve microsegmentation.

Zero Trust Network

Zero Trust Network is the idea that when an organization becomes large enough the network should not be considered trusted. This introduces the need to adopt a different approach to designing security controls and building applications.

Zero Trust Networks: Building Secure Systems in Untrusted Networks explains various approaches to get to the right level of security controls needed for a Zero Trust Network. Two foundational security controls are mutual TLS (mTLS) authentication and microsegmentation. These two security controls together can get close to what is needed in a Zero Trust Network.

Zero Trust Network is a concept that is gaining popularity in the context of container-native applications that run in multitenant environments. Furthermore, container-native apps often employ a microservices architecture in which a large number of components make it more important to have automated security controls. The below picture shows mTLS and microsegmentation used together in a container-native architecture:

Ideally, we would want a way to automate the implementation of both the mTLS and microsegmentation security controls for the components of a container native architecture.

mTLS is notoriously difficult to automate, but now we can use Istio to easily provision client and server certificates and define authorization rules. For microsegmentation, I created a prototype of a microsegmentation controller.

Microsegmentation Controller

This controller will automatically create NetworkPolicy rules around pods controlled by a service based on a specific annotation. The NetworkPolicy allows inbound traffic only via the ports that are defined by the service. It is relatively simple logic, but it proves the idea of ongoing security assessments. In fact, the microsegmentation controller continuously checks the current state against the desired state.

To set up the controller follow these instructions.

You have probably noticed that this controller is using the meta-controller framework. This project makes it easy to build Kubernetes controllers when they fall in one of the managed patterns.

Once the microsegmentation controller and Istio are correctly installed, you can configure your pods for Zero Trust Network by annotating the services as follows:

annotations:

  auth.istio.io/8080: MUTUAL_TLS

  io.raffa.microsegmentation: 'true'

Conclusions

Declarative firewall rules, in the shape of NetworkPolicies, will help us build more secure architectures by increasing automation, without decreasing the usability of the systems. NetworkPolicies are a building block that will allow vendors to build more sophisticated security tools.