3 Best Practices for Improving Microservice Security

Improving your microservice security isn’t like improving the security of a monolith application. Microservices provide lots of flexibility for application developers. They make scaling your application quicker and easier, and they let teams effortlessly deploy new features.

But when it comes to security, microservices bring a unique set of challenges.

The good news is, with a bit of planning and some diligence, you can overcome all of these challenges. In this post, we’ll talk about three key ways to improve your organization’s microservice security and how to best put them into practice.

Microservice Security Practice #1: Network Security

One of the most significant differences between microservice security and securing a monolith is how each type of application approaches the network. A monolith application will often have very few places where network traffic reaches out to the server. Oftentimes, it’s just one location, usually a proxy or load balancer.

The same is true for network egress on a microservice. Often, network connections will come from one location, synchronously wait for the monolith to complete the work the client requested, and receive the application’s response. This simplifies network security for the monolith.

The same can’t be said for microservices. Instead of doing many things and accepting connections from one source, microservices serve a small, specific job and accept connections from lots of other servers. This means that you can’t create a short list of acceptable inbound connection requests. But that doesn’t mean you have to accept every inbound request.

Rather, you should maintain a list of acceptable connection origins for each microservice you support. Often, instead of accepting connections from one point, you’ll be able to narrow down the acceptable list of connection origins to a VLAN. This VLAN will probably be where some other subset of your microservice architecture lives.

The critical part of this security step is considering where valid connections to your microservice will come from. If you do that, you’ll quickly be able to narrow down the acceptable origin list.

The tedious part here is that you need to do this for each of your microservices. That’s going to take some time! You’ll also need to spend time reevaluating this security list regularly. Bringing on new microservices will probably mean that your origin list will change over time.

Microservice Security Practice #2: Container Security

One of the keys to the microservice architecture is the container, a lightweight virtualization mechanic whereby a single physical service can virtually run dozens or hundreds of small application virtual machines. So, as you might guess, microservice security depends on getting container security right. Container security depends on three key attributes:

• image security
• securing the container itself
• securing the host that runs the container

Image Security

When we build a microservice application, we create an image, which is a snapshot of that application running on a container. If you have a docker image, you can run it on any system that supports docker, and it’ll run exactly the same. This is one of the great benefits of containerization: your application runs the same no matter the environment. But this means that securing your images is critical.

You probably store your images in a repository like Docker Hub. It’s critical to make sure that when you build, the images you use are the ones you intend to use, and not an image placed there by an attacker. One easy way to compromise microservice security is by replacing good images with compromised ones. Ensure that only authorized users can access and update your images to keep them safe.

Container Security

Securing the container is a lot like securing a traditional monolith. You want to ensure that your container doesn’t expose any unnecessary ports and only accepts encrypted traffic. Your container should authenticate any external hosts that connect to it using pre-shared secrets. You need to validate the libraries that run on your container to ensure that they don’t have any exploited security vulnerabilities.

If you find vulnerable libraries, you know how to fix them: security patches! Once you’ve patched your libraries, you’ll build a new container image and push it to your repository. Once you’ve done that, you’ll deploy it to your application environment.

Host Security

If you’ve secured your images and containers, the final major step is securing the hosts. There are a variety of security measures you should implement on your hosts. For a brief overview, you should prevent your containers from starting with elevated system privileges. A container that possesses elevated privileges can break out of the sandbox it runs in and interfere with other containers.

A savvy attacker might combine a library vulnerability in one of your containers with elevated permissions to take over all containers running on your host. Another key host security measure is to ensure that the container can’t open network connections or write to file systems that aren’t strictly necessary.

Microservice Security Practice #3: Monitoring and Alerting

Microservice security doesn’t just mean preventing an attacker from compromising your systems. It means ensuring your systems are available when you need them, any time of day.

A microservice that crashes is no better than one an attacker takes offline: neither is ready to do what you need. Monitoring and alerting help keep your microservices online. One of the most significant benefits of microservices is that you can orchestrate containers to maintain high application availability. That doesn’t mean that you can’t turn off your monitoring systems, though.

Sure, one container in a microservice swarm going down isn’t likely a cause for concern. But what if ten containers crash all at once? What if each time a container tries to come back online, it crashes again? These are things you need to know, and you need to know them quickly.What’s more, monitoring and alerting are critical to more traditional security concerns, too.

Often, the first indication that you’ll get about a security breach comes from your application logs. The best monitoring and alerting services will tell you when your services are behaving strangely. And a solid alerting system means you’ll get a notification instead of waiting to find the issue in the logs yourself.

Microservice Security Is a Marathon, Not a Sprint

As any good security engineer will tell you, each day brings a new set of challenges.

You won’t be able to flip a couple of switches and change a config file, then stop thinking about microservice security forever. Sorry if you were hoping for a silver-bullet solution.

Instead, microservice security requires diligence, attention to detail, and persistence. The good news is, there are absolutely tools that can make your job easier. Integrating a tool like OpsLevel’s Service Maturity framework will help you automate many microservice security processes.

OpsLevel automates best practices for your microservices while monitoring the ones running and alerting you if anything goes wrong. And OpsLevel’s maturity scorecards will look at your system holistically to illustrate how your long-term commitment to security makes you safer over time.

Securing microservices is indeed a lot of work. Some teams might look at all that work and decide some half measures are good enough. If you don’t want to be a part of that team, remember that microservice security is a marathon, not a sprint. Try to get a little better each day, and before you know it, you’ll be in a better place than ever.

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.