Source – itproportal.com
In the world of microservices, the goal is to have a small piece of software that performs a well-defined set of tasks. Microservices are software applications that are self-contained. They are small, independently deployable modular services that run a unique process and communicate through a well-defined, lightweight mechanism to serve a specific goal.
Typically, clear boundaries are set with regards to what your microservice can or cannot do. The move to microservices requires not only a change in architecture, but also a solid foundation of trust between the different teams who are working together to develop these microservices. Building this trust gives them the confidence they need to rely on the services’ availability and adherence to the agreed upon service contract for standard APIs.
Without a high level of trust between teams of developers, chaos will quickly ensue in your development organisation. Each team will build whatever they want and/or change APIs without notifying the rest of the organisation. In this state of disarray, functionality will break and your software development will come to a grinding halt.
While trust is extremely important in developing microservices, planning ahead for potential security issues is even more critical. Unfortunately, security considerations are often overlooked in the process of transitioning to microservices. The consequences of security failings can be devastating for your company.
For example, let’s say you are deploying a microservice that accepts input from a user and passes that input to a backend database. If your service is not secure and the input is not validated, hackers will be able to inject malicious code into the system and bring down your service — or perhaps even worse, compromise your entire system.
A plethora of microservices
As your repertoire of services and applications grows, it is probably safe to assume that the number of available microservices will grow as well. As the number of options increases, more and more security issues are bound to come up. In this post, we will review some of the issues and potential solutions that you should take into consideration before your business makes the shift to using microservices.
Reuse of code
Using shared code and libraries can help you jumpstart your move to microservices, but it can also be a double-edged sword. If you choose to borrow and use something off of the internet (i.e., an open-source solution), you are forever tied to that code and all of its shortcomings.
On one hand, reuse of industry standard technology can be a good thing since it has already been tested and used around the world. On the other hand, widespread usage of standard technology can be problematic. If a component vulnerability surfaces, your company and other companies that are using the technology will need to apply emergency patches to mitigate critical flaws in all of your applications. Imagine what it would be like to have to either deploy all of your services again because of a new security package, or to patch the servers with a whole new binary. Such a scenario sounds like a nightmare, doesn’t it?
Take the Heartbleed bug for example. When the bug was discovered in April of 2014, approximately 66 per cent of the internet’s web servers needed to be patched because the software that included the vulnerable libraries was used on almost all of the world’s web servers. This catastrophe required the patching and rebooting of hundreds of thousands of servers in a very short period of time.
If you happen to have a smaller number of servers, the solutions of deploying everything again or patching with a new binary are doable, either manually or with a basic amount of scripting. But when you scale, these are no longer viable options for solving your problem. In these cases with scaling, you need to have a tried and tested method of orchestration already in place in order for you to perform mass operations quickly to alleviate the problems.
Denial of service
Ensuring that your applications are secure is no easy feat, and managing a number of services that have multiple entry points from the outside can be difficult. As the number of services grow, the magnitude of this issue is amplified. Managing security groups appropriately will help you ensure that only the correct ports are exposed. Doing so can help save you and your applications a significant amount of pain and anguish if a malicious party targets your product in an attack.
Setting up a firewall application or an alternative solution in front of your system can correct a problem like this by ensuring that only the appropriate traffic arrives at your application’s front door and that it does not contain malicious codes or threats.
Traffic between microservices
Each microservice passes information from one to another. When the traffic is in a segregated part of your own network, it is safe to assume that your risk of having an eavesdropper is decreased since you are usually behind a corporate firewall, which makes you less susceptible to man-in-the-middle attacks.
When you move to the cloud, this assumption is no longer valid. Traffic between your microservices should be encrypted on the cloud. This means that, in addition to your microservices handling encrypted traffic, they will also need to ensure that the performance of your underlying applications does not suffer as a result of the extra work they have to perform with encrypting and decrypting information.
There are a number of methods that you can use to mitigate this problem. One such solution is creating a Virtual Private Cloud (VPC), which will enable you to segregate your workloads in the cloud without allowing a malicious intruder into the system who could eavesdrop on your traffic. However, this is not a foolproof solution, and it still has a number of attack vectors that you will need to address. Another option is offloading the encryption to an external service (e.g., a load balancing service) that will enable traffic protection with minimal disruption or changes to your current system.
Secret sharing
In order to make sure that your microservices are not open to the world, we suggest that you add authentication between the services in your system. Doing so will ensure that only the correct pieces are allowed to talk with each other and that they have the proper credentials to do so.
Embedding these secrets into your applications is a very bad idea. Best practices for modern architecture strongly advise against storing any credentials on your servers. Of course, this brings up the question of how you will allow applications to authenticate with each other and third-party services if the credentials cannot be stored locally?
There are a few ways to tackle this problem. One strategy is to use third-party tools or the tools and services that are already available from most cloud providers. The concept is pretty simple. When you initiate an authentication request, you ask another service to request a temporary set of credentials on your behalf, which allows you access for a set period of time. This solves the issue of longevity of credentials because they expire after a certain period of time, and because there are no credentials that are embedded in the microservice itself.
Security across the board
It is highly unlikely that those who are producing the microservice will actually belong to a single team. It makes sense that each team will develop, test, and deploy their own microservice (or set thereof). Therefore, the responsibility of securing the service cannot lie solely with a single, traditional operation security team and organisation—it should lie with all of the teams that are producing the software.
In order to ensure that your company will be protected and secure from outside attackers, we recommend that you consider some sort of partnership between the traditional OPSEC team and the developers. Establishing such a partnership will help the participants work together so that the software they are producing is secure by default, hardened, and continuously tested for compliance against a baseline of security requirements before it goes out the door. When the responsibility also lies with the teams who are creating the service, their level of engagement and awareness will definitely increase.
Code changes
The last issue we will address is the lifecycle of the application. No one writes software that is 100 per cent perfect the first time around — there will always be some bugs to fix before the software runs as efficiently as it is supposed to. For example, the foundation of Agile methodology is reiterated all the time, providing only the minimal viable product and improving as you progress with the project.
When you are dealing with microservices, there can be several changes each day. When you upgrade your application by changing or adding functionality, you will need to ensure that your code is (at minimum) the same as it was before, if not even better. This requires scanning the added code for vulnerabilities and weaknesses before the code is even deployed. You will need to tie this into your continuous integration processes so that this is performed as part of your release process.
Summary
Maintaining a secure system is usually a daunting task, and with the shift to microservices, there is an additional vector that needs to be addressed. Each microservice has its respective weak points that need to be secured, hardened, and continuously monitored for vulnerabilities.
The scope of this task should not be underestimated — as your use of microservice architecture grows, security issues become more significant and urgent. To protect yourself and your company, you should address these security issues early and often. We encourage you to use the suggestions from this post to help you with the process of securing your microservices.
