Istio HTTPS egress requires an explicit TLS origination choice

An application can move into a service mesh while its external dependencies remain outside it. The mesh then has to provide a path to those dependencies without pretending they have become mesh workloads. Vadim Eisenberg's January 31 HTTPS egress guide uses the Bookinfo details service and Google Books to demonstrate that problem. The configuration permits an external destination, but its limitations make clear that permitting a request is different from securely constraining every possible request.

I see this as one of the practical costs of introducing a mesh. Workload identity and shared traffic policy are useful, but applications still need ordinary external services. A mesh which changes how those calls are made adds operational work at that boundary. Understanding where TLS begins is necessary to explain both the resulting connection and the policy the proxy can apply.

The application and proxy divide the TLS work

The contemporary guide describes external HTTPS through an EgressRule. In the documented approach, the application sends plain HTTP to the sidecar, and the sidecar originates TLS toward the external service. The server-facing connection is encrypted, while the application-to-proxy portion is not. The destination port alone does not establish whether the application initiated TLS.

The guide's Ruby fragment makes that distinction explicit. It derives the port from an HTTPS URI but conditionally enables SSL on the HTTP client. With the mesh-specific environment setting enabled, the application omits its own TLS layer. The request still goes to the destination's HTTPS port because the proxy performs the TLS origination required on the external connection.

This arrangement is less transparent than simply adding a proxy to an unchanged HTTPS application. The application has to know which component will originate TLS or receive configuration that selects the appropriate behavior. Sending an already encrypted request through a configuration expecting HTTP would not supply the proxy with the HTTP information that the documented rule uses.

The source also states that SNI-based filtering of application-originated HTTPS is not yet implemented in this approach. That limitation explains why the guide asks the application to send HTTP. Reading the host and other request information requires a representation available to the proxy. Keeping TLS inside the application hides those HTTP details from an intermediate sidecar.

An egress rule names the external destination

The configuration uses the contemporary config.istio.io/v1alpha2 API. This fragment captures the guide's external destination rule, including its wildcard host and HTTPS port.

apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
  name: googleapis
  namespace: default
spec:
  destination:
    service: "*.googleapis.com"
  ports:
    - port: 443
      protocol: https

The wildcard includes several subdomains in one destination declaration. Its scope is consequently broader than a single Google Books endpoint. The rule permits the documented external traffic shape, while the application selects the particular API request. A user who intends to enable only one external dependency needs to understand what the destination expression includes.

The guide demonstrates that removing the rule restores the failed external call without redeploying the application. This shows the distinction between application rollout and mesh configuration. A service can remain running while a dynamic routing configuration changes whether its external request can complete. Diagnosing the resulting error requires examining the rule as well as the application's process state.

Connectivity rules do not establish hostile-workload isolation

The older guide explicitly says these egress rules are not a security feature. For HTTP-based protocols, the configuration relies on the domain in the request. It does not verify that the request's destination IP matches its Host header. A malicious workload can therefore present an allowed host while directing traffic toward a different address.

That is a narrower guarantee than an external access policy which prevents an untrusted application from choosing an unauthorized destination. The sidecar can provide the intended path for a cooperating application without establishing that broader guarantee. The source calls for separate enforcement, such as a firewall or another proxy outside Istio, when securing egress is required.

I regard that explicit limitation as useful design information. It lets an operator separate the successful Bookinfo demonstration from a claim about containment of malicious workloads. Both concerns involve outbound traffic, but they require different evidence. Restoring a valid external call establishes connectivity through the configured proxy, not comprehensive control of all outbound communication.

The historical guide also excludes tracing, telemetry collection and Mixer checks for this egress path. This limits the operational evidence available from the mesh itself. Permitting the external request does not automatically give an operator the same policy and observation facilities used elsewhere in the application.

The guide also distinguishes external server TLS from mesh mutual TLS. The external service uses one-way TLS, while mesh mutual TLS supplies identities for internal service-to-service communication. Enabling the latter does not change who originates the external connection described here. The original HTTPS egress article addresses that external dependency boundary, and the historical copy records the EgressRule behavior and limitations relevant to this January discussion.