Apparently migrating your application to a microservice model didn’t solve all your problems. Who could have predicted this would hapen?
Kubernetes is a platform that has revolutionized the world of application development, from lifecycle management to scalability architecture. All of thhe components that you used to manage with a fleet of VM instances about as big as your EC2 monthly bill, now lives inside of a group of containers that scale up and down on capacity (and costs!) as necessary. The dream scenario of pay-as-you-go. But as it’s always the case, a new design pattern implies a new cyberattack front to defend.
Let’s explore what can happen in a microservices-oriented model, and how we can find out about it and prevent it from affecting us.
Why does microservice isolation not stop attacks?
This is only partially correct. As everything we find on this industry today, a good part of that depends on how you manage it. For example, after getting rid of the traditional monolith model, an attacker with shell access from your web server (or web container, in this case) doesn’t have automatic access to your database backend, because it’s in a completely different container. Why doesn’t that completely stop attacks that involve accessing your database? Well, the problem is that your web application still needs access to your database backend, and thus still neets to have access credentials mounted on the system to be able to use them.
Does this mean the microservice architecture is useless and I should go back to the monolith?
Not exactly. It is true that a potential attack vector still exists in the microservice architecture, but this atack model is very different compared to the ones used against a monolithic system. It hasn’t solved all of your problms, and it’s not worse than the last design you had, it’s just that your security paradigm has changed. It requires more access layers to execute an attack, which helps you defend using the onion layer model, a more powerful defense than the alternative. Think it as a compromise that requires you to learn a new threat landscape, in exchange of letting your application scale much faster and better as required for a better adjusted cost.
I like the idea. Can I use the defense tools I already know?
At the application level, for example a web application or site, the tools are the same you already know and love. A WordPress is a WordPress, wether you install it in a LAMP stack on a Raspberry Pi or in a horizontally scalable container cluster. At an infrastructure level, however, it’s a different story. New stack, new defense. If you use a managed Kubernetes cluster from a cloud provider like AWS, you probably can’t even access your cluster nodes through SSH. The bruteforce threat disappears, but in exchange, what is an attacker finds your Kubernetes API endpoint and manages to start a malicious container? Would your current monitoring stack alert you?
What parts of the paradigm do I need to protect?
Kubernetes is a container orchestration tool that at first glance can seem like an impossible to assume level of complexity, but if we separate it in its simple purposes to make it into manageable pieces (like with microservices!) we end up discovering that there are two main pillars to protect: resources (what you deploy in your cluster), and infrastructure (how you configure your cluster). Let’s tackle these topics one by one.
The first one, more developer-oriented, covers what do we need to check when we speak about application design and how we deploy it. For example, Kubernetes configures a flat non-segmented network for all pods, where all containers can reach any other container in the cluster. If you don’t allow your VM fleet to live in a flat unmanaged network, you should not let your microservices do either. Check what secrets and credentials can your resources see from production and development. Check what the service account attached to your web pod can do, because it might surprise you. Good permission management will allow you to use the Kubernetes horizontal scalability capability without sacrificing security or isolation.
On the other hand we have the cluster configuration. If an attacker finds your Kubernetes cluster API endpoint, think about what they can do with it. If anonymous authentication is enabled, your attacker can do a very strong first information gathering step that will be very useful for future attacks. Any information discovered about your cluster can be used against you.
I should check all of this, but it’s a big task to handle by hand…
The Open Source community has your back. You don’t need to check all your resources looking for risks that you may not understand, or that don’t even know they exist. Let specialized tools do the hard work for you and focus on makin your infrastructure more secure. The tool list is long for any part of the development cycle you need to check.
Are the images coming out of your CICD pipeline secure? Snyk and Trivy will give you the CVE alerts you need in a neat and categorized report. Doubts about what the third-party stacks on your cluster are doing? Falco is on the lookout for any suspicious behavior inside your cluster to give you actionable alerts. Is your cluster properly configured? kube-bench will show you what security improvements need to be applied to your API server, plus some quality recommendations you can use to step up your security posture. The list of tools to protect your new infrastructure model is endless and they deserve a good look, wether they are community-driven or require a license.
Learning these tools looks like a learning curve
Geko can take that weight off of your shoulders. Instead of investing valuable work time in learning a series of constantly evolving tools and rules, you can let the Geko team the task of finding this information and giving you actionable reports to act upon. Like the idea? Let’s have a chat and find out how we can give you peace of mind while you keep working on what matters to you.