Owen Garrett, head of products, NGINX
Owen Garrett, head of products, NGINX

Microservices can make application development and delivery a rapid, seamless process by decomposing what would otherwise be a monstrous, monolithic application into a set of individual independent and manageable services. This architecture is well aligned with iterative, agile development and is made technically possible with tools like containerisation. It's a good business fit with API-driven use-cases and it's a good structural fit with the DevOps movement. 

Many of today's largest and fastest-growing organisations, like Netflix, Uber and Lyft, have already taken the plunge, whether by transitioning to microservices, or by adopting microservices for new applications right out of the gate. 

However, a microservices architecture has different security risks than a monolithic architecture and when looking to incorporate microservices into your IT environment, it is important to understand and address these issues up front. 

Microservices have larger attack surface than monoliths 

Microservices-based applications are very different than those built in a single large monolith. Shortly after breaking an application into individual services, organisations often realise that this opens a potential Pandora's Box of opportunities. They can grant direct access to internal data and services to trusted clients using the APIs and Web Endpoints, but this access creates a larger potential attack surface, which must be firmly secured. 

Securing APIs is a different challenge to securing typical web traffic 

Microservice applications use APIs heavily for internal communication. Because of this it makes sense to expose some of these APIs externally and to rely on rich Javascript clients to generate web pages and views on the client device. As a result, securing APIs is a different challenge to securing typical web traffic. 

In many ways, it is easier to secure APIs than it is to secure complex HTML transactions carried over HTTP traffic. APIs are more structured, with well-defined authentication and authorisation measures, and well-defined and easily understandable request and response formats. However, APIs can offer much richer functionality and can expose sensitive internal information, so it is essential to carefully audit all externally-accessible APIs to determine both the information they can reveal and the internal systems that they touch. 

In many cases, it is easier for organisations to construct specially-sanitised APIs for external consumption, delivered with security measures like rate-limiting, detailed logging and circuit-breaker patterns, than it is to attempt to secure an internal API. 

If you are exposing one or more APIs for external access, API gateways are a good idea   

Rather than having a client make requests to each microservice directly via its public endpoint, some form of an API Gateway enables a single entry-point into the system. This does not need to be a specialised device - for many use cases organisations will use an intelligent reverse proxy which enables them to inspect, authenticate, and rate-limit API requests, acting as a gatekeeper and only allowing requests that meet appropriate criteria and logging all transactions.   

Organisations should ensure that all API traffic is encrypted using TLS - Transport Layer Security - and that each API client is authenticated using both an application identifier - and API key or other shared secret - and a user identifier (an SSL certificate or OAuth token). Anonymous API requests should also be required to use a unique user identifier, to apply rate limits and to log traffic. 

Don't ignore the internal security of a microservices application 

It is always beneficial to remain suspicious of other components in the application. Although they may be completely trusted today, there are no guarantees on how the client base for the application will grow tomorrow. As a result, organisations should standardise on using TLS for all internal communications and build certificate validation of both clients and servers into the architecture from the beginning. While there is a performance impact from doing this, accelerating proxies can offload and optimise these encrypted connections to minimise any impact. 

One effective way to secure internal traffic is to use SSL encryption for all network traffic, with a PKI (public key infrastructure) that provides for fine-grained authentication and access control for all internal traffic. 

So, before jumping into microservices with both feet, it is imperative that organisations understand and address the specific security challenges a new architecture might bring to each specific environment. By solving these issues up-front, organisations can be well equipped to benefit from the flexibility and scalability microservices can bring. 

Contributed by Owen Garrett, head of products, NGINX  

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media or Haymarket Media.