This post originally appeared in Container Journal.
Microservices are nothing new. Neither is the conversation about best practices for securing microservices. Typically, that conversation centers on strategies like making each microservice as small as possible in order to minimize your attack surface, preventing unnecessary interactions between microservices so that a breach of one service won’t compromise the others, and securing network endpoints.
Those are all good practices for keeping microservices applications secure, and I certainly recommend following them.
For most teams, however, that is easier said than done. When it comes to actually implementing these microservices security strategies, obstacles tend to arise quickly.
The antidote is automation. It’s only by embracing automation that you can operationalize microservices security best practices.
Let’s explore how automation makes microservices security possible. This is a topic I discussed in a recent podcast with The New Stack, and I’d like to elaborate on some of those concepts here.
What Makes Microservices Security Different
Microservices have been widely used for years. Their cousin, Service Oriented Architecture (SOA), is even older.
Yet despite the fact that most of us are familiar with microservices now as a deployment concept, it can be easy to overlook the ways in which microservices change the game from a security perspective. In several key security-related ways, microservices are fundamentally different:
- A microservices environment contains more services that need to be monitored on an individual basis. This is the most basic and most obvious difference between microservices and monoliths, but it’s one that has crucial security implications. The more microservices you have, the more areas you need to watch for signs of a vulnerability or intrusion.
- Microservices environments are constantly changing in scope and configuration. Port addresses are updated. Endpoints change. Entirely new microservices may be added to an existing application. All of this dynamism means that monitoring for security issues manually is often impractical.
- Microservices create more complex traffic patterns. With a microservices application, you have to monitor not only the external network traffic, but also the complex network of communications between microservices. Anomalies within internal communications are often your first sign of a security issue.
- Microservices deployment technologies, like containers, lend themselves to new security strategies, like immutable infrastructure. When you deploy microservices in containers, you can update individual microservices by pushing out a new container image. This is something that is much harder to do with monoliths, and it can improve security significantly because it allows you to avoid the unexpected consequences that tend to follow live patching. It also makes it easier to detect malicious activity by looking for changes to a configuration or service that were not triggered by an immutable infrastructure update.
All of the above means not only that microservices require you to revamp your overall security strategy and tools in order to accommodate a rapidly changing, highly scalable application environment—It also means that you should rethink the processes that you use to operationalize your security strategy.
Why Automation Enables Microservices Security
How do you do that? You embrace automation. Without automation, implementing microservices security best practices is not at all practical.
(I hesitate to say it’s impossible because technically, if you have a very large team, a huge amount of patience and/or a very small environment to manage, you probably could pull off effective microservice security without the help of automation. But I would not recommend it. And I certainly don’t think you can do it efficiently at scale.)
When you automate, you can monitor as many microservices at once as you need. You can also monitor internal network communications, no matter how complex they are. And you can deploy updates automatically using immutable infrastructure principles, while also adjusting your security monitoring policies and tools in real time as your environment’s configuration and scale change.
Taking full advantage of automation starts with having the right tools. You want your deployment, orchestration and monitoring tools to be as automated as possible. That means that they can operate with a minimum of human oversight and intervention. Ideally, they’ll also be able to configure themselves to the fullest extent possible, so that even setup does not require significant manual effort.
Automation for microservices is about more than just tools, however. You also want to ensure that your CI/CD processes are automation-friendly. By that, I mean that they should support automated handoffs, while also allowing for manual interventions to take place without disrupting the rest of the pipeline. If you notice a security issue with a particular microservice during testing, for example, you’ll want to be able to have your developers intervene to fix that issue without slowing down the delivery of other microservices.
Finally, I’d extend the automation argument even to your people. Obviously, you can’t automate human behavior (at least not yet—and I’m not sure doing so would be a good idea from an ethical standpoint, anyway). But you can instill an automation-first mindset within your team. Whenever your engineers face a problem, their first thoughts should be of ways they can build an automated solution. That may not be possible in every case, of course, but automation should be the go-to strategy. At the same time, your team should strive to reap the full benefits of automation by ensuring that they put the time it creates to good use by completing tasks that simply can’t be automated, such as assessing overall application design in order to improve security.
Microservices security might be possible to pull off using manual tools, processes and mindsets, but it’s not practical. Organizations that succeed in securing microservices are those that adopt an automation-centric strategy, enabling them to put microservices security best practices into— well, practice.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
What Integrated Security Really Means — and Why It MattersRead the Blog
A DevOps Approach to Compliance: What It Really Takes to Build Compliant AppsRead the Blog
CISOs: 5 Essential Features in a Cloud Native Security PlatformRead the Blog
Making CI/CD Fast and SecureRead the Blog
Leveraging Webhooks for Security Alerts with TwistlockRead the Blog