Source: searchcloudsecurity.techtarget.com
Microservices offer tremendous flexibility to developers, adding speed and versatility to the application development process and thus enabling developers to focus their time more closely on business logic instead of the underlying application plumbing.
However, the approach is not without its tradeoffs.
One major challenge to deploying and managing a microservices architecture is scale. Imagine an environment where hundreds or thousands of microservices are in use and a REST API’s endpoint for a core service within an application must be changed. This might involve modifying code or configuration everywhere that service is called from, which can range from dozens to hundreds of places. Implementing this in one fell swoop would be difficult and time-consuming, to say the least.
To mitigate these microservices challenges, many developers use a technology called service mesh. This infrastructure layer adds traffic and communication management to microservices without the need to build that logic into service endpoints or callers.
Service mesh is also compelling from a security point of view because it removes barriers to making security configuration tweaks. As a result, the overall posture of services in the application’s landscape can be bolstered.
Istio is one example of a service mesh architecture that is growing in popularity. Let’s take a closer look at why service mesh implementation is gaining popularity, along with the specific security benefits Istio offers to developers.
Microservices security with service mesh architecture
Service mesh enables the decoupling of service communications from the application logic of that service via a sidecar proxy — an extended version of the Envoy proxy — that picks up responsibility for managing traffic and communication between services.
For context, consider two situations. In the first, two web services exchange data directly. This default web service API interaction is displayed below. The service on the left may request a URL from the service on the right using an HTTP verb, such as GET, to make the request and receive a serialized result set back — perhaps a JSON-serialized object.
In the second situation, two services have had their communications decoupled from the application logic. Sidecar proxies gate communication pathways between these services and communicate with a control plane. This enables the distribution of policy and collection of log and metric data. It also provides a mechanism for central management.
Interaction points and communications between services in the mesh, known as the data plane, occur at a different level than management of components and definition of the policy rules that govern how those components interact — i.e., the control plane. Separating these elements into two distinct groups provides several benefits. First, it enables IT pros to control the flow of traffic through policy. Now, they can tweak policy in one place. It also gives them peace of mind knowing the enforcement of that policy will trickle down and be picked up by all nodes in the mesh. Second, it provides a hook between component interactions where they can gather information, log important data items, monitor service health and gather telemetry information.
Examining Istio service mesh security features
With this in mind, it is time to look more closely at the Istio security model. More specifically, IT pros should be knowledgeable about the set of security features they can use in an Istio service mesh architecture deployment to help forward the organization’s security goals. This explainer will also help organizations that have deployed alternative service mesh technologies, such as Linkerd.
Security teams can take advantage of multiple noteworthy Istio features to make their jobs a little easier. For example, each service within the mesh has its own identity. To support this, certificates are distributed to individual services, and the Istio daemon (istiod) keeps keys rotated and certificates within their validity period. Thus, a policy can allow or disallow individual services from making use of other services without having to code this logic into the application itself. Instead, rules are created via policy (YAML files) that specify what can talk to what, what groups or namespaces given services belong to, and how — and under what circumstances — they can talk to each other.
Another Istio service mesh security feature that can benefit infosec teams is the ability to control TLS authentication within the mesh. Several different authentication modes can be supported using Istio, including the following:
- Permissive mode. Workloads can use either HTTP or mutually authenticated TLS — TLS where both sides of the connection use certificates to authenticate — for intercomponent communication.
- Strict mode. All workloads use mutually authenticated TLS. Requests not employing TLS are not permitted.
- Disable mode. Mutual TLS is not employed.
The ability to enable or disable mutual TLS authentication is valuable to security teams but is not the only way to authenticate access to a resource and authorize a requesting party. To add more granularity, facilitate policy development and enable more detailed logging of requests, Istio uses JSON Web Tokens (JWTs) defined in RFC (Request for Comments) 7519. JWTs add granularity to microservices authentication and access control requests. JWTs are JSON-serialized access claims that enable a policy enforcement point — in this case, the proxy — to validate that a requester does in fact have access to a resource. This means security teams can write rules that allow per-resource access to a given resource.
In addition, Istio introduces the ability to gather information and telemetry about the operation of the environment. Metrics enable the collection of performance data from the Envoy proxy — for example, timing and traffic metrics about the performance of individual requests. Istio service mesh architecture creates service-level metrics that provide additional information about service communications and controls metrics that provide information about the Istio mesh itself. It can also be used to keep detailed access logs about accesses to individual services, as well as access traces across the mesh — i.e., to understand how a given request propagates across the application.
There are other Istio service mesh architecture features that can be enabled and used from a security point of view as well. The Istio model provides significant security value to the security team in a shop that has microservices applications at scale. For a microservices application, moving to a service mesh — whether Istio or another product — can equip the security team with flexibility to effect security changes en masse that would be difficult to do without an automated approach, making it a valuable tool in the practitioner’s toolbox.
