Istio 1.0 makes mutual TLS migration an explicit operating mode

An existing service cannot require every client to join a mesh at the same instant. That coordination problem has limited how mutual TLS can be introduced into running applications. The Istio 1.0 announcement on July 31 makes incremental mutual TLS deployment a central part of its production-readiness claim. Permissive authentication mode gives the migration a supported intermediate state while clients change how they connect.

I regard workload identity as one of the strongest reasons to operate a mesh. It gives policy a more useful basis than a network address which can change as workloads move. The cost remains substantial, since certificates and proxy configuration become dependencies of ordinary service communication. A practical migration mode helps introduce that dependency without requiring an application-wide cutover.

The release marks networking APIs and multicluster support beta while declaring a core set of functionality suitable for production. Those labels describe the scope of the milestone more precisely than the version number alone. The notes also list unsupported or broken cases. Production readiness is an assessment of the supported core, not a statement that every installation mode has identical behavior.

Server acceptance and client origination are separate choices

The release replaces service annotations with authentication policy coupled to client-side destination rules. Permissive mode allows mutual TLS to be rolled out without first updating every client of the service. It is an intermediate acceptance policy, so its purpose differs from requiring that every request arrive with a mesh identity.

That distinction matters when interpreting a successful request. During migration, a service can continue accepting clients which have not adopted mutual TLS. Connectivity alone does not establish that all traffic now uses authenticated workload identities. The client-side decision about originating TLS and the server-side decision about accepted traffic have to be understood together.

The Bookinfo destination rules shipped in 1.0.0 show the client-side setting. Each service's rule puts ISTIO_MUTUAL under its traffic policy. The same resource also defines the named subsets used for routing to workload versions. TLS behavior and subset membership coexist in the destination declaration but express different decisions.

For the details service, the relevant shape is as follows.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

This configures how traffic to that destination uses TLS. It does not, by itself, describe the server's entire authentication acceptance policy. Reading it alongside the applicable authentication policy explains the two sides of the connection. Treating the destination rule as a complete declaration of the service's security boundary would omit the receiving side.

Authentication does not decide every access question

Istio 1.0 also moves authorization policy evaluation into Envoy. The announcement says RPC-level authorization no longer requires Mixer and its adapters. That changes the placement of the decision in the request path. The local proxy can evaluate authorization without depending on an external Mixer call for that functionality. The distinction affects both configuration ownership and request processing.

Authentication and authorization still answer different questions. A mutual TLS connection establishes identities for its participants. Authorization policy decides which requests those identities may make. Introducing certificates without a corresponding access policy does not express an application's intended permissions. Conversely, a permission rule needs the identity information on which it is meant to operate.

I find local evaluation useful because the availability of a shared policy service should not become an unnecessary dependency for every access decision. It also changes where to look when diagnosing a rejected request. The operator needs to examine the policy delivered to the proxy and the identity attached to the connection, rather than assuming every authorization result came from a Mixer adapter.

The release separately supports JWT authentication through authentication policies. That gives the mesh an end-user authentication mechanism alongside service-to-service mutual TLS. Those identities can coexist in an application request, but they describe different participants. A workload certificate does not become an end-user token simply because both travel through the same sidecar.

TLS routing does not require HTTP decryption

Networking changes in the release introduce TLS sections in VirtualService for routing by Server Name Indication. Ports identified as TLS or HTTPS can use those routes. Without an accompanying virtual service, the notes say those ports are treated as opaque TCP. The proxy's ability to route a connection consequently depends on how the port and routing object are configured.

This extends the distinction between handling a TLS connection and reading its HTTP contents. An SNI match can choose a destination using the name supplied during TLS negotiation. It does not imply that the sidecar has access to the encrypted URL path. Application-originated TLS and proxy-originated TLS have different consequences for which request details are visible to the mesh.

The routing changes also make the transition away from the old model concrete. Istio 1.0 removes the old networking APIs and deprecates the previous Istio ingress, disabling it by default. Gateway is the recommended replacement for that ingress behavior. An existing installation needs to account for edge configuration as well as internal service routing when adopting the release.

The command-line migration support changes too. The networking conversion command is removed, while an experimental ingress conversion command is added. These are different transformations. A tool which once translated route configuration is not evidence that every old resource can still be submitted to the new release. The actual resources expected by the installed control plane determine what remains supported.

Production operation includes the configuration system

The 0.8 ADS implementation illustrates the configuration-delivery model already introduced before this release. Proxies maintain discovery streams and report errors for rejected updates. That relationship remains relevant to understanding a security policy rollout. An accepted configuration object and an active proxy decision are connected by generation and delivery work.

Istio 1.0 adds istioctl proxy-status and istioctl authn tls-check. Their inclusion recognizes that an operator needs tools to inspect the proxy and authentication state. A mesh with correct desired policy can still need diagnosis at the point where a proxy uses it. The release's operational tooling accompanies the new migration behavior rather than replacing the need to understand it.

The telemetry path also changes. Mixer buffers report calls before passing data to adapters, allowing batch processing, and it adds a second-level policy-check cache alongside the sidecar cache. Those mechanisms address repeated work in shared infrastructure. They concern external policy and telemetry operations, while the newly local authorization path has a different dependency structure.

The release also introduces client-side telemetry in addition to server-side telemetry. This gives an interaction more than one possible observation point. A client can observe an attempted call differently from the server which receives it, particularly when connection establishment fails before a request reaches its destination. Selecting the observation point is consequently part of interpreting what a measurement represents.

Out-of-process Mixer adapters provide another change in how the mesh's shared infrastructure can be extended. The release describes initial support and identifies it as the recommended direction for adapter integration. This separates adapter implementation from the Mixer process boundary. It does not move every policy decision into an adapter, since authorization has separately moved into Envoy. An operator needs to identify which extension and decision path a particular configuration actually uses.

Multicluster support provides another example of why scope matters. The release brings it to beta for communication and consistent policy across clusters. Its known issues also say that Mixer components do not connect to remote clusters' Kubernetes APIs, leaving some remote-workload metadata incomplete. Cross-cluster connectivity therefore does not establish identical telemetry fidelity for local and remote workloads.

Helm becomes the recommended installation method, with customization intended to support selective adoption. The notes identify an EKS limitation requiring manual sidecar injection and disabled Galley, and they report broken raw-VM mesh expansion. Those are specific deployment boundaries to interpret alongside the production claim. They do not change the mutual TLS migration mechanism, but they affect which environments can participate in the intended installation.

For an existing application, permissive mode provides a way to keep communication working while clients acquire mutual TLS configuration. The Bookinfo destination rules show the explicit client setting, and authentication policy determines what the service accepts. Completing the security change requires understanding both sides, including the remaining clients which still rely on the migration policy's broader acceptance.