If you’re building a modern application and know what your security requirements are, you can leverage very powerful cloud-based services. These services will give you world-class security without the need to hire security experts or spend a lot of time worrying about it. You can focus on the core business logic that your customers are primarily interested in.
When I last wrote about best practices for securing microservices, many users were already very deep into the microservices world, and some were quite successful within it. Nevertheless, microservices were still somewhat surrounded by mystery, and best practices based on real-world experience were not always available.
On top of that, a lot of the managed services on the market were still primarily focused on monolithic applications or based on a very simplistic, “hello world”-style view of what a microservices application would look like.
Much has changed. For starters, many more businesses have bought into microservices and have even gone as far as joining the serverless revolution. As both a cause for and an effect of the increased adoption, lots of useful services have emerged that make developing microservices much easier.
Virtually all the best practices available in my previous story are still viable and highly recommended for securing your microservices. But today you want to look at ways to implement microservices security with greater efficacy, with much less effort or needed expertise.
Here’s how to simplify your microservices security.
User identity and access control
I previously recommended the use of OAuth 2.0 for managing user identity and ensuring appropriate access control. While OAuth 2.0 is not a perfect method, when you use such a commonly adopted standard, your projects can be built without reinventing the wheel and potentially creating vulnerabilities that the software engineering community as a whole has already faced and solved.
This is still the sensible approach, but you need to take it one step further.
You can now leverage super-secure yet easy-to-use managed services such as Amazon Cognito. With such services, you can simply follow a well-defined set of steps that will get authentication, authorization, and user management working for your application with best-in-class security and enormous scaling capabilities.
Equivalent services exist from smaller players as well as other cloud providers, such as Auth0, Okta, and Google’s Firebase. (Okta acquired Auth0 in March 2021, but specific product plans have not been announced.) The concept remains the same: first-class security standards, and massively scalable capabilities with very minimal effort.
Defense in depth
Previously, I applied the military notion of defense in depth in securing microservices. To recap:
“Defense in depth” is defined as “an information assurance concept in which multiple layers of security controls (defense) are placed throughout an information technology system.”
In plain English, what you need to do is identify what your most sensitive services are, and apply a number of different layers of security to them, so that a potential attacker who is able to exploit one of your security layers will still have to figure out a way to beat all your other defenses on your critical services. This is by all accounts easier said than done, but several resources are available.
The key point is that you need to ensure that appropriate security measures are applied to each microservice, rather than just relying on an API gateway as a protection around all of your microservices. According to research by Jandera, Braubachb, and Pokahrc, with an API approach, “a hacker only needs to find a weakness in the gateway to get access to any of the hidden back-end microservices.”
The ecosystem of managed services is still not as sophisticated as in other microservice areas, though, and more needs to be done to make defense in depth for microservices both easy to implement and obvious to understand.
That said, with a little bit of discipline, you can achieve defense in depth by using well-established identity and access management (IAM) cloud services. You just assign individual IAM roles to each microservice and apply the principle of least privilege for both inbound and outbound communication. This way, attackers who are able to exploit a microservice, will be severely limited in terms of how much damage they can inflict on the rest of the system.
If you’re running in the cloud, you can simply leverage super powerful services such as Amazon KMS, Azure Key Vault, or Google Cloud KMS for managing your encryption keys, and use something such as Secrets Manager for storing your sensitive information.
From a libraries standpoint, AWS Encryption SDK, GoDaddy’s Asherah, and Google’s Tink are client-side libraries that make it easier to encrypt and decrypt data in your application. By leveraging these services, you can put yourself in a position where you can encrypt everything easily from day one.
The perspective I want to bring to the table in terms of security updates is aptly summarized by Amazon developer advocate Nathan Peck in this tweet:
Frankly, in 2021 it is quite hard to think of reasons for not using containers and/or serverless technologies to build your microservices.
One of the main benefits of using managed container and function services is that you can build things quickly and focus on your business logic while security is handled by the cloud provider.
Managed container services worth noting and adopting are Amazon Fargate, Google Cloud Run, and Azure Container Instances. A special mention also goes to RedHat’s OpenShift which offers a managed (and simpler) Kubernetes experience.
Serverless functions services (FaaS) include the undisputed leader Amazon Lambda, but also Google Cloud Functions and several others.
By choosing to build your application on managed containers and/or functions you effectively delegate responsibility for system security updates to your cloud provider.
Zero-trust architecture (ZTA) is a relatively new idea that some organizations are starting to believe in and adopt. In the words of security specialist Michael Wasielewski, zero-trust architecture “is a model where application components or microservices are considered discrete from each other and no component or microservice trusts any other.” In other words, each microservice should inherently distrust any input coming from the network (regardless of how well protected such network may be) and should instead adopt measures that allow it to trust a connection.
In my opinion, ZTA today is where defense in depth for microservices was five years ago. It is a great idea that deserves consideration and may well need to be adopted by some (but not all) projects.
We are, unfortunately, still far away from seeing any managed service or tool that can help us automate the process of establishing a ZTA. But good work has been done on it. The UK’s National Cyber Security Centre has developed 10 principles that you can evaluate and adopt as part of your ZTA strategy. Amazon Web Services has published some reference architectures as well that can help you get a sense of what it may look like if you’re on AWS.
Get your containers out of the public network
The advice in 2017 was to make sure that all of the containers running your microservices are behind an API gateway. With an API gateway such as Amazon API Gateway or Google’s Apigee you can ensure that a single, well-secured entry point exists for all of your microservices. Meanwhile, your microservices are protected behind a firewall and can never be reached apart from the API gateway.
That was not as obvious an idea a few years ago as it may sound now. But today, those services have become even easier to set up, and some well-established patterns have been developed that reflect real-world experience.
So the best practice remains the same, but services and technologies have evolved that make taking your microservices out of the public network much easier to accomplish.
Monitor everything with a tool
In 2017, I suggested that it would be unwise to build a microservices-based application without the ability to confidently monitor everything.
Back then, while still relatively new, Prometheus was by far the best available option. Extremely powerful, highly configurable, and, most of all, built with microservices in mind.
Today, Prometheus is available as a managed service from AWS and others. This makes it even easier to get started with, since you don’t need a team of seasoned Prometheus experts to set it up for you.
But other options are available as well. In fact, the advice today is to start out with a simpler service such as DataDog, New Relic, Amazon CloudWatch, or Azure Monitor. These services are so easy to configure and use, and so inexpensive, that there is really no reason not to adopt them from day one.
In the serverless world, where in the early days there was no really easy way to monitor all of your functions, things are much more mature these days. Services such as those from the Israel-based companies Lumigo and Epsagon are now widely adopted, while others such as Dashbird have been gaining a lot of momentum.
A growing body to cover
While security best practices for microservices have remained largely the same, the ecosystem has greatly evolved and expanded. Cloud-based managed services can make adhering to such best practices easier and more immediate. Projects can and should achieve high security standards from a very early stage without the need to hire security specialists until they are much bigger.
As you embark on building your next microservices-based project (or securing an existing one), make sure to understand what the primary security best practices are, and then confidently delegate of many of those as possible to powerful cloud-based services such as the ones suggested in this article. This will ensure scalable security and position your microservices project for future growth.