Istio 1.7 strengthens workload identity and gateway defaults

A VM workload needs a way to obtain its first mesh identity before certificate rotation can maintain it. Istio 1.7 improves both stages. The VM bootstraps from a short-lived Kubernetes service account token, and its workload certificate then rotates automatically. This extends the identity lifecycle beyond a running proxy's ability to present an existing certificate.

The August 21 release announcement emphasizes security and non-Kubernetes workload operation. It explicitly keeps VM support at alpha maturity. The new bootstrap and rotation mechanisms therefore improve that integration without changing its overall status to a stable feature.

I consider workload identity the strongest foundation Istio offers for access policy. Its value depends on how identity is provisioned and renewed, as well as how requests use it. A service account token and an automatically rotating certificate make those lifecycle stages concrete for a VM joining the mesh.

Bootstrap and ongoing identity have different jobs

The 1.7 change notes specify the short-lived token used for VM bootstrap. That establishes an initial credential for obtaining workload identity. Certificate rotation then maintains the identity material used by the workload after it has joined. Treating them as separate stages helps explain why an integration needs both.

The announcement uses a mixed deployment as its example, with frontends in Kubernetes calling stateful backends on VMs. The aim is to support mutual TLS across that boundary while giving workloads their own identities. This does not require every backend to move into Kubernetes before the service relationships can use mesh authentication.

Operation improves alongside provisioning. istioctl proxy-status can validate the status of a non-Kubernetes proxy using proxy configuration supplied through a file. The release also adds official RPM packages alongside the existing Debian packages. Those changes address installation and diagnosis around the identity mechanism, which matter when the proxy does not live in a Kubernetes pod.

Gateways receive less privilege by default

Gateway deployments now run as non-root by default. The change notes identify similar improvements for istiod and the operator, and a more rigorous operator security context. These defaults reduce unnecessary process privileges in components that administer or carry traffic for the mesh.

Running as non-root and checking a request's identity answer different security questions. Process privileges constrain the software executing the proxy. Identity checks help determine what traffic that process should accept or forward. The release includes changes in both areas without making one a replacement for the other.

For TLS origination from an egress gateway, DestinationRule client certificates and CA certificates gain SDS support. The announcement calls out the ability to provision client certificates as Secrets. It also emphasizes certificate rotation for file-mounted DestinationRule certificates at gateways. That connects another certificate use case to the secret distribution lifecycle.

Trust-domain enforcement covers TCP

Trust Domain Validation now applies to TCP traffic as well as HTTP. The announcement also says it supports trustDomainAliases in MeshConfig. This expands the protocol coverage of an existing identity check, rather than introducing workload identity for the first time.

The release repairs gateway source-principal authorization when the server TLS mode is ISTIO_MUTUAL. That is a specific combination of authentication and authorization behavior. The gateway must obtain the peer identity in a way that lets the source-principal policy evaluate it correctly. The presence of an encrypted connection alone does not establish that a source-principal rule has been respected.

The new analyzer warning for DestinationRules that omit CA certificates addresses another distinction. A TLS configuration can be present while lacking the CA material used to validate server identity. The analyzer helps identify that configuration risk. It does not infer the intended trust relationship for every external service.

I prefer these mechanism-specific improvements to a broad claim that turning on the mesh completes security. VM bootstrap, gateway privileges, and peer authorization have different enforcement points. Their configuration has to agree for the resulting communication to have the properties the operator intends.

Startup can wait for the proxy

The release adds values.global.proxy.holdApplicationUntilProxyStarts. It is disabled by default. When enabled, the injector puts the sidecar first in the container list and configures it to block the other containers from starting until the proxy is ready.

The purpose is to support applications that need proxy-mediated access immediately at startup. Without such ordering, an application can begin its initialization before the proxy is ready for the requests it sends. The option turns that dependency into startup behavior instead of requiring the application to assume an ordering that has not been established.

This also changes the dependency visible during failure. Waiting for proxy readiness means the application cannot complete that startup stage while the proxy remains unready. That follows from the option's defined blocking behavior. It is a deliberate choice for applications whose startup traffic needs the proxy, not a default imposed on every workload.

Observability becomes less bundled

Telemetry add-ons are no longer installed by default through istioctl, and that installation path is deprecated. The release directs users to integrations for their installation. At the same time, Prometheus metrics merging becomes enabled by default, and the patch corrects merging so application failures do not cause Envoy metrics to be dropped.

The distinction is between exposing metrics and owning the deployment of every tool that consumes them. Istio can improve the metrics path while leaving the monitoring system's lifecycle with its operator. The release also removes inaccurate control plane metrics instead of retaining names whose values do not describe the system correctly.

Operator installation gains revision flags for initialization and removal. This lets the operator participate in multiple-control-plane upgrades, extending the revision workflow to an installation method that previously could not use it.

For VM workloads, the practical improvement is a more complete operational path, including initial identity, renewal, packaging, and status diagnosis. Gateways gain less privileged defaults and more complete identity enforcement. Each has a documented scope, and VM integration remains alpha even as these particular mechanisms become more usable.