Approaches to Securing Decentralised Microservices
Before microservices, we had Service-Oriented Architecture (SOA). The theory behind SOA largely was correct: avoid ad-hoc application integration by taking a service- or function-centric approach to integration. The objective was to simplify integration complexity via a modular architecture with reusable components. Then somehow SOA became synonymous with the enterprise service bus (ESB), ESB-centric architecture looks great on paper (and it does make for elegant diagrams!).
The unexpected consequence of this approach was that rather than reducing integration complexity, it centralised it at the ESB and with the integration team. Orchestration, service discovery, data integrity and transformation were now under the responsibility of a single team and solution. Not to mention that XML-based SOAP standards such as WADL and WS-Trust are notoriously complex.
The microservices architecture (MSA) was the response to these issues, and it is impossible today to discuss decentralised API security without learning from the SOA mistake and understanding the reasons for the MSA approach, whilst also understanding the unique API security challenges of this approach.
The goal of the microservice approach is to deliver small, domain-bounded, and independent services which leverage the use of mature standards to ensure scalability greater ease of integration, and reduced reliance on a centralised orchestration platform.
With the principle of MSA being “dumb pipes, smart endpoints”, this translates to self-contained API-exposed services with little to no centralised orchestration. Yet care must be taken to avoid introducing an ESB — and all its related issues — by another name.
The Centralised API Gateway Approach (or, ESB by another name)
The diagram below shows the traditional, centralised approach for API security. A single, centralised API Gateway (API-GW) is placed between external consumers and the organisation’s services. Regardless of whether the gateway is cloud-based or on-premise, logically the segmentation between areas of differing trust levels is performed on the network.
The above approach of dividing the network into trusted and untrusted zones is remarkably similar to the SOA n-tier architecture approach and presents a number of weaknesses.
Scalability. Concentrating most API management and security features within a single product leads to this centralised solution becoming the key bottleneck. Even if the solution does not hit compute power or network bandwidth constraints, configuration complexity can slow down the Ops team considerably. This leads to productivity inefficiencies due to complexity constraints.
Security. Unmanageable configuration complexity coupled with a single logical point of failure increases the likelihood of security incidents caused by misconfiguration.
Organisational. In response to the burdening complexity of the solution and the resultant request backlog, the team managing the API-GW will attempt to “push out” the complexity burden onto the network, identity and Dev teams. This often results in development teams finding creative shortcuts to meet product iteration deadlines by custom coding API security functionality within services. Common functionality becomes duplicated inconsistently across multiple services. This increases the likelihood of security incidents caused by inconsistent application of secure coding practices.
Breaking down complexity with product-centric vertical segmentation
Horizontal segmentation is the well-known defence-in-depth approach of network zoning and segmentation based on the level of trust of each zone and the sensitivity of the systems placed within each zone. It has its uses, and regardless of the hype around “zero trust” evangelists, most enterprises aren’t Google and the defence-in-depth approach is mildly appropriate. The diagram below depicts the standard horizontal zoning of network zones along differing levels of trust.
Vertical segmentation, on the other hand, segments the enterprise along product lines or business units. It compliments horizontal segmentation and is critical to approaching decentralised API security approaches. This vertical segmentation can begin with as simple an exercise as designing a scalable API endpoint and OAuth token audience namespace. These namespaces form the basis for coarse-grained API authorisation: tokens and endpoints must have a matching “audience” attribute, with a “default deny” in place for cross-channel token validity.
The API Microgateway simplifies API and microservices architectures, enabling developers to configure security and traffic management policies in a gateway that’s external to their API and microservices implementation. The benefits of this approach include enhanced operational robustness and scalability. Some vendors providing this approach include Apigee, Nginx and WSO2
The Istio Service Mesh
The key differentiator of the Envoy sidecar proxy with Istio approach from the API Microgateway pattern is its placement, which is within the clusterised Docker container, typically Open Shift or Kubernetes, rather than on the network layer. Although many API Microgateway vendors offer container integration SDKs, making this distinction less than clear-cut.
An Istio service mesh makes use of Envoy sidecar proxies, which it injects into both sides of the network. This enables it to provide advanced service discovery, security, visibility, advanced routing and load balancing features, as well as integration with commercial or open source OpenID Connect Secure Token Services for access control.
Container clustering and management such as Kubernetes and OpenShift until now has remained focused on providing elastic infrastructure for containers, but it hasn’t moved up the stack to provide throttling, service discovery, security and load-balancing to manage how these containerised workloads interact with each other.
This is principal challenge that Istio was created to address: the management of containerised microservices at scale. And I must admit, I’m finding Istio is one of the most exciting technological trends to appear in recent times. I can’t wait for it to mature more and be ready for large-scale production use.
In order to ensure agility, flexibility and improve application security, the design principle should be to avoid coding security functions within products or applications and avoid centralised architectures where scalability is a key concern.
- Offloading routing, service discovery and security elsewhere is not sustainable approach, as we’ve seen with SOA and ESBs.
- OpenID Connect provides the standard for access control interoperability between APIs and API management approaches, thus reducing the reliance on any single proprietary API management vendor or decentralised solution approach.
- It might be worthwhile investigating novel approaches such as the Istio service mesh, whilst being aware that this approach is still relatively immature, and API micro-gateways might be more appropriate in the interim