Istio Service Mesh for Microservices: Team Roles and Responsibilities

A service mesh is an infrastructure layer that takes over communication between microservices: it encrypts traffic, routes it and collects telemetry without changes to application code. With Istio, the platform team runs the control plane, gateways and mesh-wide policies, application teams handle routing and authorization in their own namespaces, and security sets the target mTLS mode.

Quick Overview

What you will learn:

• What Istio is made of and what it gives microservices
• How choosing sidecar or ambient mode changes who does the work
• What belongs to the platform team, application teams and security
• What to check before picking a managed offering from a cloud provider

Who this article is for:

• Architects and platform team leads
• DevOps and SRE teams running Kubernetes clusters
• Application team leads and security specialists

Reading time: 7 minutes

What Istio Does for Microservices

Istio has a control plane (istiod), which takes your desired configuration and programs the Envoy proxies, and a data plane made up of those proxies, which sit in the path of traffic between services. The features teams actually use are:

• mutual TLS (mTLS): every service gets an identity encoded in a certificate, and istiod automates key and certificate issuance and rotation;
• traffic rules: routing, splitting traffic between service versions, timeouts and retries;
• authorization policies: rules with ALLOW, DENY and CUSTOM actions enforced in Envoy;
• telemetry: metrics, logs and traces for traffic between services.

The traffic rules rest on two resources. A VirtualService defines how requests are routed to a service, and a DestinationRule defines what happens to traffic once it reaches that destination, such as load balancing or connection settings (istio.io).

The project’s governance has matured too: according to www.cncf.io, Istio joined the CNCF at the Incubating level on 30 September 2022 and moved to Graduated on 12 July 2023.

The Deployment Mode Shifts the Workload Between Teams

The documentation on istio.io describes two data plane modes. In sidecar mode every pod gets its own Envoy. In ambient mode traffic goes through a ztunnel proxy on each node (Layer 4), and Layer 7 features are added where needed through waypoint proxies. The same documentation says ambient mode has been production-ready for single-cluster use since version 1.22, and its comparison table lists it as stable for single clusters only.

For team roles, one row of that comparison on istio.io matters most: in sidecar mode the application developer manages the proxy lifecycle, while in ambient mode the platform administrator does. Adding a workload to the mesh means restarting pods in sidecar mode, but only labelling a namespace in ambient mode. If application teams would rather not deal with proxies, ambient moves that work to the platform team. The trade-off is that Layer 7 authorization and telemetry need waypoints, and someone has to plan them.

Who Owns What

Istio stores policies in a hierarchy. A mesh-wide policy lives in the root namespace, a namespace-wide policy in its own namespace, and a workload-specific policy carries a non-empty selector. Each workload gets the narrowest policy that matches it (istio.io). That hierarchy maps neatly onto team roles:

• Platform team: installs and upgrades istiod, runs the ingress gateways and owns the mesh-wide policies in the root namespace, such as a PeerAuthentication with mode: STRICT. It also owns the upgrade schedule.
• Application teams: configure routing, traffic splitting and authorization policies for their own services in their own namespaces. Kubernetes RBAC is how they get those rights: a Role grants permissions within one namespace, while a ClusterRole applies cluster-wide (kubernetes.io), so application teams get namespace roles, not cluster ones.
• Security: sets the target mTLS mode and authorization rules, reviews mesh-wide policies and drives the migration. PERMISSIVE mode lets a service accept encrypted and plain-text traffic at the same time, which makes it a transition state before switching to STRICT.
• SRE and observability: use the mesh telemetry to keep services reliable and to respond to incidents.

One rule is worth writing down explicitly. A mesh can have only one mesh-wide PeerAuthentication policy and one per namespace, and Istio ignores newer duplicates. Changes at that level should be approved by the platform team and security together.

Upgrades and Managed Offerings

According to the Supported Releases page on istio.io, a new minor release ships roughly once a quarter, and each is supported until six weeks after the N+2 minor release. The control plane may run one version ahead of the data plane, never the other way round, and the project recommends upgrading through revisions. Upgrades are therefore a standing quarterly job for the platform team, not a one-off project.

A managed offering does not take all of that off your plate. Check the details at the source before you choose:

• Google Cloud: Anthos Service Mesh and Traffic Director now run as Cloud Service Mesh, which supports the Istio APIs for Kubernetes (cloud.google.com).
• Azure: according to learn.microsoft.com, the Istio add-on for AKS does not yet support ambient mode and is not upgraded when the cluster auto-upgrades, so keeping the mesh revision current stays with your team. The older Open Service Mesh add-on loses AKS support on 30 September 2027, the upstream OSM project has been retired, and Microsoft advises migrating to the Istio add-on.

Read Also

• Migrating From Docker Swarm to Kubernetes: a rollout plan for team managers
• Container Image Security Scanning: catching vulnerabilities before deployment
• Kubernetes Autoscaling With HPA and VPA: scaling workloads in practice

Build Your Skills

Two trainings cover this topic: Building Service Mesh With Istio and Kubernetes and Kubernetes Design Patterns and Best Practices. The first covers traffic management and security policies in Istio; the second covers design patterns for applications on Kubernetes. Get in touch to tailor the scope to your team.

Frequently Asked Questions (FAQ)

What Is a Microservices Architecture, and Where Does a Service Mesh Fit?

A microservices architecture splits an application into small services that talk over the network and are deployed independently. A service mesh takes over that conversation: it encrypts it, authenticates the services, routes traffic and collects telemetry. Teams no longer have to rebuild that logic in every service.

Who Should Run Kubernetes and the Service Mesh?

In the author’s view, a platform team is the natural owner: it looks after the clusters, the Istio control plane, the gateways and the mesh-wide policies. Application teams manage the configuration of their own services in their own namespaces, and security sets the rules for mTLS and authorization. It is worth agreeing on the split in a responsibility matrix before the rollout.

What Do Platform Teams and SREs Do Around a Service Mesh?

A platform team treats the mesh as a product for application teams: it installs and upgrades it and ships secure defaults. Google, on sre.google, sums up SRE as “what happens when you ask a software engineer to design an operations team”. Around a mesh, SREs use its telemetry to keep services reliable.

How Do You Secure Network Traffic in Kubernetes?

At the IP address and port level, you use NetworkPolicy objects, which only take effect if the cluster’s network plugin supports them (kubernetes.io). A service mesh adds mTLS encryption, service identity and authorization based on that identity. The two work together: NetworkPolicy limits who can connect, and the mesh checks who is on the other end.