Last Updated on October 11, 2023 by KnownSense
Human error and misconfigurations account for a large number of security breaches. So it’s a best practice to minimize development involvement as much as possible. Hence, you could decouple the security from your microservices by putting it into a service proxy, which manages the traffic flow in and out of your microservices. The proxy can then vet each request before it reaches the microservice and perform authorization and authentication, security logging, certificate rotation, and much more. Typically, to control all these proxies and configuration and keep them in sync, there is a centralized control plane, which manages the proxies. This is also known as the sidecar pattern. The sidecar pattern can handle a lot more than just security. It can also do load balancing, service discovery, health checks, circuit breaking, and failover policies, metrics, telemetry, you name it, and this is what is known as a service mesh. It decouples all this from your microservices so the development team can focus on the business‑critical requirements, which pay the bills. Now let’s take a closer look at how Istio, a service mesh, handles microservices security.
Service Mesh with Istio
Istio uses an envoy proxy as its sidecar. Envoy is an open source edge and service proxy designed for cloud‑native applications. If we were using Istio with Kubernetes, the envoy proxy would be wrapped in a container and placed into the same pod alongside the container with your microservice. So both are decoupled from each other and can have a different software development lifecycle. But because they are in the same pod, to the outside world, they resemble one unit with a single IP address and entry point. The sidecar container intercepts all traffic before forwarding it to the microservice container. Now all the sidecars together is known as the data plane in Istio. The data plane is managed by the Istio’s control plane. Again, these are decoupled from each other and hence can be independently scaled and configured. Operators create policies, and these policies are then pushed out to the sidecars via a component called Pilot. Let’s see how a microservices architecture would look like with Istio service mesh. We want JWT validation, hence we create a policy. In this case, Pilot would source the public key of the authorization server and configure each sidecar with it so that you can validate tokens. We also want to give an identity to all these microservices. For this, we can use mutual TLS by providing each sidecar with a certificate. This is handled by a component called Citadel. By default, it generates certificates valid for 1 hour, so very short lived. They refresh every 30 minutes to ensure there is no downtime due to a delay of rotating the certificate. These are SPIFFE certificates, which are basically X.509 certificate with a SPIFFE ID in them. Now that all the microservices have identities, we can configure authorization within our mesh.
Why Istio?
Service‑to‑service authorization
Istio supports coarse‑grained service‑to‑service authorization, basically whitelists where services are allowed to communicate with each other, even down to the HTTP method. Hence, you can limit which services are allowed to form GET and PUT operations on a particular microservice. So we could limit the impact of our pricing service pod being compromised by preventing it from being able to send requests to any of the other microservices.
JWT Support
Istio can also be configured to interrogate their JWT scopes and claims. Hence, we can perform more finer‑grained authorization by using the claims and scopes on the token.
Authorization as a Service
Istio can also handle Authorization as a Service for you. Basically, the sidecar will make a call to a component called Mixer. Mixer will forward the request to an authorization adapter. A popular one is Open Policy Agent. This effectively is the policy decision point, which can call out to policy information points to source more attributes like Active Directory or Open LDAP and then make an authorization decision returning either yes or no to the sidecar. Now this can introduce some additional latency, but Istio does mitigate some of that by providing caching where it caches previous decisions. And if a request is for the same policy with the same attributes, it will reuse the authorization decision and not call the mixer. The mixer is also responsible for collecting metrics from the sidecars, etc. On successful authentication and authorization at the sidecar, the token is an also passed to the microservice so it can perform even finer‑grain authorization. I believe there are plans to even include the SPIFFE ID.
Ingress gateway
Istio also has an ingress gateway which handles routing of all incoming traffic into the sidecar and a separate egress gateway for all outgoing traffic, which is a nice separation of concerns and allows you to control where your mesh connects to. Now this is just a high‑level view of what a service mesh is and what Istio brings to the table, and it can be a whole course in itself.
Now you’re probably scratching your head. What about the API gateway? Is it now redundant? And what about all the other concepts we have learned in the previous modules? Shall I just go straight to the mesh? The answer is it depends.
Service Mesh vs API Gateway
The service mesh definitely seems like it’s the next evolution of microservices architecture. It decouples a lot of the non‑functional requirements from your microservices. It ticks all the boxes from single responsibility principle, provides a zero‑trust network, centralizes and standardizes security auditing, provides short‑lived certificates, automated key rotation, Authorization as a Service, supports polyglot architectures. It basically allows your development teams to focus on the functional requirements, which pay the bills, and significantly reduces the chances of misconfiguration, which is a big culprit of security breaches. However, it is still early days with the service mesh. The technology is not yet mature enough for all use cases. For example, your typical API gateway does a lot more than just security, routing and load balancing, observability, logging, resiliency. A lot of the API products are actually more like API management products. They provide additional features like analytics, which help generate reports for API usage, KPIs, or client engagement, reports to businesses and stakeholders, monetization features if you’re charging for the usage of your API, developer tools from API documentation, testing, discovery, and support. In the mesh, this is still a developing area. But vendors are slowly starting to trickle into this space and supporting the mesh, like, for example, Kong. So, the answer is still it depends. If you’re working on the greenfield microservices project, then yes. Definitely consider using the mesh. Or, at the very least, design your architecture so that you can position into the mesh in the future. However, in reality, a lot of the microservices systems you might find yourself working on will probably be legacy systems that are in the process of transitioning into a microservices architecture for perhaps large organizations that have dependencies on an API management product they’ve already purchased. So it won’t be possible to go from a monolith to a mesh right away. Generally, the transition will be from a monolith to façade services to microservices. And then, in the future, perhaps the mesh. Or who knows, something else. Hence, as a developer, you will encounter all kinds of microservices architecture with all types of constraints, so there is no one size fits all.
Conclusion
The page delves into microservices security strategies, particularly the concept of a service mesh like Istio. It emphasizes the importance of separating security from microservices to minimize development involvement and reduce the risk of human error and misconfigurations. The service proxy in a service mesh manages traffic, performs security functions like authentication, authorization, and certificate rotation, and more. Istio, for instance, utilizes an envoy proxy as a sidecar, which intercepts and manages traffic for microservices. The page highlights the benefits of service-to-service authorization, JWT support, and Authorization as a Service within Istio. It discusses the potential transition from API gateways to service meshes and underscores the evolving nature of this technology in the context of microservices architecture.