🤦 Let's not do that mistake again!

Make sure to mentally separate security requirements from security implementation.

Here is why this is so important.

What is wrong with sticking to security implementation?

🚩 I see many companies struggling to adopt containerization technologies like Kubernetes.

Why? Among others, because their IT policy states something along the lines of “network communication between VMs must be segregated via firewalls”.

Needless to say, such a policy is unsuitable for containerized workloads, since the communication between applications is best segregated between Pods and not VMs.

😟 It makes me sad to watch engineers configure firewalls between Kubernetes Nodes and pinning Pods onto Nodes, just so they could implement what would feel like an apples-to-apples security implementation.

😞 At the end, they aren’t getting the benefits of containerization, nor a proper implementation of their security requirement. What a waste!

Focus on security requirements

✨ The solution: Let go of the security implementation and go back to the security requirement.

E.g., “We need to implement ISO 27001 A.13.1.3 Segregation in Networks to reduce the risk of data leaks. How can we implement that?”

Going back to the security requirement opens up a whole new world of possibilities:

  1. You can use NetworkPolicies, supported by most Kubernetes Container Network Interface (CNI) implementations. They watch Pods creation/destruction and configure kernel-space at layer 4 firewall rules accordingly. The latter may be implemented using iptables, IPVS or a custom eBPF data plane.

  2. You can use a service mesh, like Istio. Service meshes first direct all inbound and outbound Pod traffic through a proxy. This is achieved kernel-space at layer 4. The proxy, generally Envoy, is then configured to allow/block inbound/outbound traffic. At the end, you get a “layer 7 firewall”.

  3. You can run many Kubernetes clusters and segregate communications between them. If combined with (1) or (2), this can further reduce blast radius and segregate communication between applications. For example, you might have a Kubernetes cluster for front-office applications – which is exposed publicly – and one for back-office applications – which handles more critical data, but is only exposed internally.

What about you?

Did you face confusion between security requirement and security implementation? How did you solve it? Please share your story by commenting on this LinkedIn post.