Istio Service Mesh

Istio handles ingress routing and service-to-service security in the cluster.

Why Istio?

The cluster needs to expose multiple services on different IPs and ports - web apps, mail protocols (SMTP, IMAP), LDAP, and container registry. Istio's Gateway API implementation provides a unified way to configure all of this, regardless of protocol.

Additionally, the mail system has complex internal routing (postfix → dovecot → databases) that benefits from mTLS and explicit access control between services.

Ambient Mode

Traditional Istio injects a sidecar proxy into every pod, which adds resource overhead and complexity. The cluster uses ambient mode instead - a newer approach where a single ztunnel DaemonSet on each node handles mesh traffic for all pods.

Namespaces opt-in with istio.io/dataplane-mode: ambient. Databases opt-out with istio.io/dataplane-mode: none since they don't need mesh features and the proxy can interfere with database protocols.

Gateway Per Service

Each major service gets its own Istio Gateway with a dedicated MetalLB IP:

Service	Why separate Gateway?
Mail (user-ingress)	Non-HTTP protocols (SMTP/IMAP) on standard ports
Mail (lists, studi)	Different hostnames, separate TLS certificates
IDP	Mixed protocols (HTTPS + LDAPS on 636)
Tickets	Simple HTTPS, isolated from other services
Registry	Internal use, different access patterns

This isolation means a misconfiguration in one gateway doesn't affect others, and each service can have its own TLS certificate lifecycle.

Authorization Policies

The cluster uses a default-deny security model. Every namespace has an empty AuthorizationPolicy that blocks all traffic, then explicit allow rules for each valid traffic path.

This matters for the mail system where:

• Only the user-ingress gateway should reach postfix submission
• Only postfix should reach dovecot for local delivery
• Only the lists gateway should reach mailman-web

Without these policies, any compromised pod could talk to any service. The policies encode the expected traffic flow and reject anything else.

Certificate Management

Istio's mTLS needs a CA to issue workload certificates. Rather than using Istio's built-in CA, the cluster integrates with cert-manager via cert-manager-istio-csr. This keeps all certificate management in one place - the same cert-manager that handles Let's Encrypt certificates for ingress also handles internal mTLS certificates.

Inspecting

Gateway and route status:

kubectl get gateways,httproutes,tcproutes -A

Authorization policies:

kubectl get authorizationpolicies -A

Configuration

• clusters/main/infrastructure/essentials/istio.yaml - Helm releases
• clusters/main/infrastructure/essentials/cert-manager.yaml - CA integration
• clusters/main/apps/*/namespace.yaml - Ambient mode labels
• clusters/main/apps/*/*/mesh.yaml - Authorization policies per service