Security was mostly perimeter-based while building monolithic applications. This means securing the network perimeter and access control using firewalls. With the advent of microservices architecture, static and network-based perimeters are no longer effective.
Nowadays, applications are deployed and managed by container orchestration systems like Kubernetes, which are spread across the cloud. Zero trust network (ZTN) is a different approach to secure data across cloud-based networks. In this article, we will explore how ZTN can help secure microservices.
What is Zero Trust Network (ZTN)?
Zero trust network is a security paradigm that does not grant implicit trust to users, devices, and services, and continuously verifies their identity and authorization to access resources.
In a microservices architecture, if a service (client) receives a request from another service (server), the server should not assume the trustworthiness of the client. The server should continuously authenticate and authorize a client first and then allow the communication to happen securely (refer to fig. A below).
Fig. A – A Zero Trust Network (ZTN) environment where continuous authentication and authorization are enforced between microservices across multicloud
Why is a zero trust network environment inevitable for microservices?
The importance of securing the network and data in a distributed network of services cannot be stressed enough. Below are a few challenges why a ZTN environment is necessary for microservices:
- Lack of ownership on the network: Applications moved from perimeter-based to multiple clouds and data centers with microservices. As a result, the network has also got distributed, giving more attack surface to intruders.
Increased network and security breaches: Data and security breaches among cloud providers have become increasingly common since applications moved to public clouds. In 2022, nearly half of all data breaches occurred in the cloud.
Managing multicluster network policies has become tedious: Organizations deploy hundreds of services across multiple Kubernetes clusters and environments. Network policies are local to clusters and do not usually work for multiple clusters. They require a lot of customization and development to define and implement security and routing policies in multicluster and multicloud traffic. Thus, configuring and managing consistent network policies and firewall rules for each service becomes an everlasting and frustrating process.
Service-to-service connection is not inherently secure in K8s: By default, one service can talk to another service inside a cluster. So, if a service pod is hacked, an attacker can quickly hack other services in that cluster easily (also known as vector attack). Kubernetes does not provide out-of-the-box encryption or authentication for communication between pods or services. Although K8s offers additional security features like enabling mTLS, it is a complex process and has to be implemented manually for each service.
Lack of visibility into the network traffic: If there is a security breach, the Ops and SRE team should be able to react to the incident faster. Poor real-time visibility into the network traffic across environments becomes a bottleneck for SREs to diagnose issues in time. This impedes their ability for incident response, which leads to high mean time for recovery (MTTR) and catastrophic security risks.
In theory, a zero trust network (ZTN) philosophy solves all the above challenges. Istio service mesh helps Ops and SREs to implement ZTN and secure microservices across the cloud.
Please read top 10 pillars of zero trust network considered by top CISOs.
How Istio service mesh enables ZTN for microservices
Istio is a popular open-source service mesh implementation software that provides a way to manage and secure communication between microservices. Istio abstracts the network into a dedicated layer of infrastructure and provides visibility and control over all communication between microservices.
Istio works by injecting an Envoy proxy (a small sidecar daemon) alongside each service in the mesh (refer to fig. B). Envoy is an L4 and L7 proxy that helps in ensuring security connections and network connectivity among the microservices, respectively. The Istio control plane allows users to manage all these Envoy proxies, such as directly defining and cascading security and network policies. (More on Istio architecture and its components will be explained soon in another blog.)
Fig B – Istio using Envoy proxy to secure connections between services across clusters and clouds
Istio simplifies enforcing a ZTN environment for microservices across the cloud. Inspired by Gartner Zero Trust Network Access, we have outlined four pillars of zero trust network that can be implemented by Istio.
Four pillars of zero trust network enforced by Istio service mesh
1. Enforcing Authentication with Istio
Security teams would be required to create authentication logic for each service to verify the identity of users (humans or machines) that sent requests. This is necessary to ensure the trustworthiness of the user.
In Istio, it can be done by configuring peer-to-peer and request authentication policies using PeerAuthentication and RequestAuthentication custom resources (CRDs):
- Peer authentication policies involve authenticating service-to-service communication using mTLS. That is, certificates are issued for both the client and server to verify the identity of each other.
Below is a sample PeerAuthentication resource that enforces strict mTLS authentication for all workloads in the foo namespace:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
mtls:
mode: STRICT
- Request authentication policies involve the server ensuring whether the client is even allowed to make the request. Here, the client will attach JWT (JSON Web Token) to the request for server-side authentication.
Below is a sample RequestAuthentication policy created in the foo namespace. It specifies that incoming requests to the my-app service must contain JWT that is issued, and verified using public keys by entities mentioned under jwtRules.
apiVersion: security.istio.io/v1beta1
kind: RequestAuthenticationetadata:
metadata:
name: jwt-example
namespace: foo
spec:
selector:
matchLabels:
app: my-app
jwtRules:
– issuer: “https://issuer.example.com”
jwksUri: “https://issuer.example.com/keys”
Both authentication policies are stored in Istio configuration storage.
2. Implementing authorization with Istio
Authorization is verifying whether the authenticated user is allowed to access a server (access control) and perform the specific action. Continuous authorization prevents malicious users from accessing services, which ensures their safety and integrity.
AuthorizationPolicy is another Istio CRD that provides access control for services deployed in the mesh. It helps in creating policies to deny, allow, and also perform custom actions against an inbound request. Istio allows setting multiple policies with different actions for granular access control to the workloads.
The following AuthorizationPolicy denies POST requests from workloads in the dev namespace to workloads in the foo namespace.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: DENY
rules:
– from:
– source:
namespaces: [“dev”]
to:
– operation:
methods: [“POST”]
3. Multicluster and multicloud visibility with Istio
Another important pillar of ZTN is network and service visibility. SREs and Ops teams would require real-time monitoring of traffic flowing between microservices across cloud and cluster boundaries. Having deep visibility into the network would help SREs quickly identify the root cause of anomalies, develop resolution, and restore the applications.
Istio provides visibility into traffic flow and application health by collecting the following telemetry data from the mesh from the data and control plane.
- Logs: Istio collects all kinds of logs such as services logs, API logs, access logs, gateway logs, etc., which will help to understand the behavior of an application. Logs also help in faster troubleshooting and diagnosis of network incidents.
- Metrics: They help to understand the real-time performance of services for identifying anomalies and fine-tuning them in the runtime. Istio provides many metrics apart from the 4 golden ones, which are error rates, traffic, latency, and saturation.
- Distributed tracing: It is the tracing and visualizing of requests flowing through multiple services in a mesh. Distributed tracing helps understand interactions between microservices and provides a holistic view of service-to-service communication in the mesh.
4. Network auditing with Istio
Auditing is analyzing logs of a process over a period with the goal to optimize the overall process. Audit logs provide auditors with valuable insights into network activity, including details on each access, the methods used, traffic patterns, etc. This information is useful to understand the communication process in and out of the data center and public clouds.
Istio provides information about who accessed (or requested), when, and onto what resources, which is important for auditors to investigate faulty situations, and then suggest steps to improve the overall performance of the network and security of cloud-native applications.
Deploy Istio for a better security posture
The challenges around securing networks and data in a microservices architecture are going to be increasingly complex. Attackers are always ahead in finding vulnerabilities and exploiting them before anyone in the SRE team gets time to notice.
Implementing a zero-trust network will provide visibility and secure Kubernetes clusters from internal or external threats. Istio service mesh can lead this endeavor from the front, with its ability to implement zero trust out of the box. IMESH helps enterprises to onboard and adopt Istio service mesh without any operation hassle. Check out our offerings.
About IMESH
IMESH offers solutions to help you avoid errors during the experimentation of implementing Istio and fend off operational issues. IMESH provides a platform built on top of Istio and Envoy API gateway to help start with Istio from Day-1. IMESH Istio platform is hardened for production and is fit for multicloud and hybrid cloud applications. IMESH also provides consulting services and expertise to help you adopt Istio rapidly in your organization.
IMESH also provides a strong visibility layer on top of Istio which provides Ops and SREs a multicluster view of services, dependencies, and network traffic. The visibility layer also provides details of logs, metrics, and traces to help Ops folks to troubleshoot any network issues faster.
The post Zero Trust Network for Microservices with Istio appeared first on IMESH.
Top comments (0)