Securing microservices and containers: A DevOps how-to guide

There is a simple reason for developers adopting the cloud and cloud-native application architectures. These “tools and methods” allow developers to accelerate innovation and feature delivery in the service of meeting business demands and keeping their enterprise competitive. While these tools and methods make noticeable improvements for DevOps teams, their new operational model creates security concerns and headaches for security practitioners.

DevOps methods disaggregate the neatly packaged n-tier, VM-bound application into distributed architectures. The cloud breaks the traditional perimeter structure, which is the foundation of existing security practices. Because applications are becoming increasingly distributed, APIs are a new resource that, too, need to be secured to protect the enterprise from unwarranted risks. As a result, new access control measures and compliance enforcement points are critical to overcoming this challenge.

Looking at the enablement process for microservices, two functions play critical roles: the developer and the security practitioner. Security and data privacy requirements introduce access control and encryption requirements for developers. Authorization for APIs needs to be implemented in a distributed manner, which can be challenging, and secrets management and key distribution for distributed applications also introduce overhead for the developer. Secondly, the security practitioner is focused on maintaining visibility, compliance and control all while embracing architectural transformation towards microservices.

For organizations looking for end-to-end security for their microservices and containers, there are three core tenants of an effective microservice security solution:

Comprehensive

With any microservices security stack, there are three layers involved: the container runtime (the interactions of the container with the host), network access (the network traffic between microservices), and the API layers (the unit of consumption for microservices). When focusing on any one layer, this results in a myopic protection and detection solution for two key reasons:

1. Detection: The signal to noise ratio for detecting attacks is significantly improved with the ability to correlate data for anomalies across all three layers. These signals provide greater visibility into the potential kill chain to be executed by an attacker.

2. Protection: A much more robust security solution is achieved when exercising both zero trust and least privilege access control across the three layers. The probability of a complete attack execution is severely reduced by the enablement of access control at each layer.

Identity-driven

For a microservice, the more context available to identify a microservice, the stronger it makes both the authentication and authorization policies. Service/application identity is central to authentication and enforcing authorization between microservice APIs, applications and the users. When enhancing the identity of a service:

1. Leverage vulnerability data from the container image scans. As the contextual identity of the container may change over time, so does the data over the life span of the container.

2. Understand that containers are most often part of a CI/CD pipeline that is autogenerated and carry a significant amount of metadata. This metadata can include the type of container (frontend or backend), the type of image it is running (Mongo, Redis) and/or it can include an identifying reference back to the original code commit that had triggered the creation of the specific container. This metadata can become a multi-attribute identity.

Overall, across all microservices the identity paves the way for scalable encryption. A popular encryption technique is mutual transport layer security (TLS) and part of this process is to authenticate and authorize both ends of a microservice. The identity that is assigned to a microservice becomes an integral part of the authorization process for a TLS session. In order to allow developers to focus on their business logic, it is critical to offload any Public Key infrastructure logic from the microservice.

Heterogenous

As many microservice and cloud-native adoption projects begin as a small initiative with a specific scope, there is always a brownfield deployment where microservices will have dependencies on monoliths. These services use several orchestration capabilities such as Kubernetes, VMWare or EC2 Container Services and they can be hosted in either public or private clouds. Because of this, a microservice security solution must be capable of operating in all of these environments in a heterogeneous manner.

Overall, while container threat/vulnerability management and network security are vital components of comprehensive microservice security, they are only a portion of the larger picture aimed at operating securely in Zero Trust environments. In a microservice environment, best practices for security include processes and technologies that address all aspects of core protection and visibility use cases of a distributed application. In particular, APIs and identity are often overlooked and underserved areas of cloud-native applications in most security programs. It is important to address these uses cases in a manner that does not cause additional burden on either the development or security organization.

As organizations continue to rapidly adopt microservices, it drives the growing need for security teams to completely understand the full scope of security requirements to avoid the misguided thought that legacy security solutions will accurately protect them. A combination of maintaining proper hygiene, monitoring, logging and compliance is required for a comprehensive microservices security strategy and implementation. In consideration at all layers of the security stack, it is critical to follow the principles of Zero Trust least privilege access control in a microservices environment.