I’ll be the first to say that I’m a bit of a newbie when it comes to containers, Kubernetes, and all things “cloud native”. Luckily, I’ve had the opportunity this month to participate in NGINX’s Microservices March training series and it has been amazingly informative. This four-week series is now in its third week, the focus this week is securing the scalable web applications we’ve been building over the first two weeks through use of security patterns applied to the ingress container. As someone who in the past has had the need to wrestle with traditional Web Application Filters to make sure our front-end servers aren’t mistakenly allowing public access to the back-end servers, I have to say this has been refreshing content
Like the other units, Microservices Security Pattern includes a high-level webinar featuring a Kubernetes trainer from Learnk8s, a collection of reading and videos, and a hands-on lab. If you’re registered, you can complete the lab through a browser-based environment that’s great for newbies, or if you’re up for more of a challenge you can use the lab guide to try it on your own.
Learnings from the Lab “Protect Kubernetes Apps from SQP Injection”
The Problem
Before I get into the content of what the training is teaching you how to do, I find it’s important to state the problem you are trying to solve. Often, attempts against our public facing web servers come by way of trying to pass commands through the URL string, making use of unpatched systems to pass commands that either are designed to interact with databases systems or the operating system itself. Even with our best intentions, patch management is always going to be a problem and that does nothing for you when the vulnerability is not known to the vendors. So, it is better to be able to filter out at least the worst possible options such as SELECT, DELETE, UNION or even rm -rf or format c:. This is where traditionally the web application filtering came in. Unfortunately, these were cumbersome physical or large sized virtual machines that are statically sized; unable to scale with our needs. This is where Kubernetes comes in.
The Good Solution
To fix our problem, we need to introduce filtering to the web server. With the concept of microservices, the goal is to only ever have a single task happening in a given container. So to introduce our filtering, we need to add another container to the stack here. In this case we can leverage what’s referred to as a sidecar: a very basic, vanilla NGINX container that is effectively a proxy sitting atop our app server in the same pod, doing nothing but proxying traffic to and from the app server and applying the filtering in line as needed by way of a ConfigMap. While this absolutely works, it’s not going to do anything for you in terms of load balancing or scaling.
The Better Solution
Through the first 2 weeks of this series of training we’ve been learning how to leverage NGINX Ingress Controller to provide a scalable load balancer for one or more web applications. Through the use of annotations, we can marry our need for security filtering to our Ingress solution, allowing for all our needs in one streamlined appliance. So, while we’ll still have the same benefits as the sidecar, it will easily scale and can potentially provide wider coverage to multiple applications at the next layer down.
