How to Secure Microservices: 6 Things You Can’t Forget


Microservices bring many advantages: flexibility, ease of upgrading certain parts of the application, and much more. However, they are not an ideal solution to all problems and they also have their own drawbacks. One of them is a complex mesh of network connectivity. And when you have a complex network, another problem arises: security.

The more complicated the network, the more difficult the security. And the more microservices you have, the more complicated the network. But the network is only one aspect. When it comes to securing microservices, there are a few other things you need to watch out for. But fear no longer, because in this article, you’ll learn six things that will help you secure your microservices.

How to secure microservices: what do you need to know?

Before we dive into the six things you can’t forget when securing your microservices, we need to start with some general information about securing microservices. This is important because you can’t focus 100% on the microservices themselves. When it comes to securing microservices, you need to think about your entire microservices ecosystem. This means you need to secure CI/CD pipelines, your container orchestrator, and the way you build your microservices.

1. Start with the secure base image

It should come as no surprise that when building microservices, the base image of your Docker containers plays a crucial role. In fact, a well-chosen base image is good not only from a security perspective, but it’s also good practice in general. So what does a “good” base image mean? First, forget the basic images of random people. Choose only verified images from well-known companies. For example, if you need an Ubuntu image, grab one directly from the official Docker images. It’s tempting to use third-party images that have a few extra tools built-in, but it’s better to add those tools yourself than risk using images from untrusted sources.

But using official images does not automatically give you additional security. They greatly increase your security posture, but they are not bulletproof. You have to ask yourself if you really need an image based on a real distro (like Ubuntu or CentOS images). Try using more minimalist images like Alpine or Distroless.

2. Scan your images

Even if you choose a relatively secure base image, that doesn’t mean your Docker image is secure. You will add several layers to this image yourself. Of course, you won’t intentionally introduce vulnerabilities into your own images, but don’t forget about dependencies. You might not even realize that almost everything you install brings (sometimes hidden) dependencies. That’s why it’s important to perform a vulnerability scan on your images, especially since it’s a pretty easy thing to do and some image registries even have this built-in.

Graphical User Interface Description automatically generated with medium confidence

3. Analysis of container execution

If you want to go even further, one of the best security enhancements you can make to your microservices is to implement runtime scanning. Execution monitoring is a process of monitoring every action that occurs in your container. Especially in a microservices environment, it’s really efficient because you always know exactly what needs to be running in a specific container. Therefore, anything out of the ordinary usually means trouble. Has anyone run a shell script in your container? A curl or wget command? Pretty much everything hackers would usually do is vastly different from how a normal microservice would behave. Therefore, runtime analysis scanners are really good at what they do and are a big security improvement.

4. Take good care of your secrets

In a Kubernetes environment, we tend to think we’re covered when it comes to passwords and tokens, because Kubernetes provides built-in “secret” resources. Their purpose is exactly that: securely store secrets in your Kubernetes so you don’t need to pass them in plain text to your container. But there is a catch. First, you need to somehow bring your secrets to your Kubernetes cluster first. They’re secure once they’re in, but how do you make sure they’re not plain text when you deploy them to Kubernetes?

It’s a common problem. Since everything in Kubernetes is defined as a YAML file, we tend to store all those YAML definitions in Git. But your actual passwords, tokens, and other secrets when in the YAML file (before being applied on the cluster) are plain text. So you can’t store these files in Git. And no, don’t, even if your Git repository is private. There is no one-size-fits-all solution for this as it will depend on your infrastructure and the cloud provider you are using. But whenever possible, try to use a secure secret store like HashiCorp Vault. Many secure stores have plugins or other mechanisms to securely transfer your secrets to the Kubernetes cluster.

5. The network

Last but not least: the network. If you are using Kubernetes, by default all your microservices can communicate with each other. This means that an attacker only needs access to one of them to be able to connect to anything in your cluster. And although your main back-end microservices are well secured (in terms of the code itself), there are always overlooked, unimportant secondary services that play no major role in the whole system and therefore nobody cares about it. . Well guess what, hackers love these kinds of services.

The solution is simple: implement network policies or even encryption within your cluster. There are network policy objects built into Kubernetes that allow you to implement simple network separation and rules. But there are also many other tools, some of which can even implement Layer 7 network policies.

Another possibility is encryption. There are tools that allow you to encrypt all traffic between all pods in your cluster. Encrypting all traffic doesn’t automatically make it secure, but definitely makes hackers’ lives harder.

network security photo

6. Monitor all layers

Another important security-related task is to ensure that you have a cloud-native security monitoring system. What does that mean? This means that your monitoring system is able to monitor and correlate data from all layers of your infrastructure (microservices, container orchestrator, and cloud services).

This is important because traditional on-premises systems can easily get confused in the multi-layered cloud environment. It’s critical that your tools understand cloud services and the dependencies between them. For example, when you create a DNS server in the cloud, you might not find an actual DNS server. You will find a service that works as such, but you will not find an actual machine that is your DNS server. And that can be a problem for traditional tools because they usually run on servers. And hackers like to take advantage of this and navigate between layers undetected.

Graphical User Interface, Text, Application Description automatically generated


I wish I could give you an easy-to-follow step-by-step guide to securing microservices, but the truth is that microservices-based environments are typically complex. Securing such environments also differs a lot between cloud providers, but we’ve tried to combine the most universal tips that will hopefully help you stay relatively secure. If you really care about security, be sure to check out our other articles and take a look at our free API security solution.

This post was written by Dawid Ziolkowski. David has 10 years of experience as a Network/Systems Engineer in the beginning, DevOps in between, Cloud Native Engineer recently. He has worked for an IT outsourcing company, a research institute, a telecommunications company, a hosting company and a consulting company. So he has accumulated a lot of knowledge from different angles. Today, he helps companies migrate to the cloud and/or redesign their infrastructure for a more Cloud-Native approach.

The post How to Secure Microservices: The 6 Things You Can’t Forget appeared first on Traceable App & API Security.

*** This is a syndicated blog from the Security Bloggers Blog Network written by Dawid Ziolkowski. Read the original post at:


Comments are closed.