Core Tenants of a Microservice Security Solution

The adoption of microservices and cloud-native infrastructure requires a comprehensive solution that operates across multiple layers of the security stack and is built on strong identity for policy enforcement. Three core tenants define an effective microservice security solution –

1. Does the solution address the entire microservices stack?
2. Is the solution based on the Zero Trust principles of authentication and authorization for all transactions?
3. Can it be deployed across heterogeneous environments?

Comprehensive

There are three layers in the microservice security stack:

1. Container runtime: interactions of the container with the host
2. Network access: network traffic between microservices
3. Application programming interface (API) layers: The unit of consumption for microservices

Focusing on any one layer results in myopic protection and detection solutions for two key reasons:

1. Detection: The ability to correlate data for anomalies across these three layers greatly improves the signal to noise ratio for detecting attacks. Signals from all three layers give us a better view into the potential kill chain an attacker will execute. For example we are able to correlate a runtime violation with running port scans or brute force attempts to determine open api’s on a microservice.
2. Protection: Exercising zero trust and least privilege access control across these 3 layers creates a much more robust solution. A code injection attack followed by remote shell and data exfiltration attempt encompasses multiple layers of the security stack. Enabling access control at each layer greatly reduces the probability of a complete attack execution.

Identity Driven

Service Identity or Application Identity is central to Authentication and enforcing Authorization between users, applications and microservice APIs. The more context available to identify a microservice, the stronger it makes authentication and authorization policies. Considerations for enhancing the identity of a service are as follows:

I. Leveraging vulnerability data from container image scans. This data may change over the life of a container and so does the contextual identity of the container.
II. Containers are most often auto-generated as part of a CI/CD pipeline and carry considerable metadata, such as the type of container (frontend or backend), the type of image it is running (Mongo, Redis) and perhaps some reference identifier back to the code commit that triggered the creation of this container. This metadata can become a multi-attribute identity. Identity paves the path for scalable encryption across all microservices. Mutual TLS is a popular encryption technique and part of the TLS negotiation process is to authenticate and authorize both ends of a microservice. The identity assigned to a microservice can now become an integral part of authorizing this TLS session. It is important to offload any Public Key Infrastructure logic from the microservice allowing developers to focus on their business logic.

Heterogeneous

Most microservice and cloud-native adoption projects start as small initiatives with specific scopes. There is always a brownfield deployment where microservices have dependencies on monoliths. The services can be hosted in both public and private cloud environments and use a number orchestration capabilities such as Kubernetes, EC2 Container Services or VMWare. A microservice security solution needs to operate in all of these environments.

For more on the best practices of securing microservices, read our whitepaper on Security for Microservices here.