All Products
Search

This Product

    Alibaba Cloud Service Mesh:Access external services from an ASM instance

    Document Center

    Alibaba Cloud Service Mesh:Access external services from an ASM instance

    Last Updated:Mar 10, 2026

    To allow the pods in a Service Mesh (ASM) instance to access external services, you can configure a policy for accessing external services, create a service entry, or configure a CIDR block of external services to which access is intercepted. External services are services that are not registered in Istio.

    Choose a method

    MethodTraffic visibilityWhen to use
    Set outbound traffic policy to ALLOW_ANYNone -- no Istio monitoring or controlQuick testing or development; you do not need traffic management for external calls
    Create a ServiceEntry (recommended)Full Istio monitoring and routing controlProduction workloads that need observability, fault injection, or traffic shaping for external services
    Scope sidecar interception by CIDR blockSidecar intercepts only the specified CIDR rangesSelective interception where only in-cluster traffic passes through the sidecar proxy

    Prerequisites

    Before you begin, make sure that you have:

    • An ASM instance with at least one Kubernetes cluster added to its data plane

    • Sidecar proxy injection enabled for the target namespace or pod

    • Access to the ASM console

    Set the outbound traffic policy to ALLOW_ANY

    The Outbound Traffic Policy setting controls whether sidecar proxies allow or block traffic to services not in the Istio service registry.

    • ALLOW_ANY -- Sidecar proxies pass all outbound traffic regardless of destination. External services are reachable but not monitored or controlled by Istio.

    • REGISTRY_ONLY -- Sidecar proxies block traffic to any service not in the service registry.

    Note

    To view the services defined in the internal service registry, navigate to ASM Instance > Instances Status in the ASM console.

    Important

    With ALLOW_ANY and no ServiceEntry defined, sidecar proxies forward TCP traffic to any IP address and port. This lacks explicit flow control and can cause unexpected behavior when multiple services listen on the same port. Do not rely on ALLOW_ANY for external services such as databases. Define ServiceEntry resources to explicitly control traffic routing.

    Procedure

    1. Log on to the ASM console.

    2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

    3. On the Mesh Management page, click the name of the target ASM instance, or click Manage in the Actions column.

    4. In the left-side navigation pane, choose Dataplane Component Management > Sidecar Proxy Setting.

    5. On the global tab, click Outbound Traffic Policy, set it to ALLOW_ANY, and then click Update Settings.

    Verify the configuration

    From a pod with sidecar proxy injection, run curl -I against an external HTTP and HTTPS endpoint.

    HTTP request:

    curl -I http://www.aliyun.com/

    Expected output:

    HTTP/1.1 301 Moved Permanently
server: envoy
date: Mon, 07 Sep 2020 09:28:54 GMT
content-type: text/html
content-length: 239
location: https://www.aliyun.com/
eagleeye-traceid: 0be3e0a615994709353116335ea5ea
timing-allow-origin: *
x-envoy-upstream-service-time: 67

    HTTPS request:

    curl -I https://www.aliyun.com/

    Expected output:

    HTTP/2 200
server: Tengine
date: Mon, 07 Sep 2020 09:16:31 GMT
content-type: text/html; charset=utf-8
vary: Accept-Encoding
vary: Accept-Encoding
strict-transport-security: max-age=31536000
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-readtime: 0
eagleeye-traceid: 0b57ff8715994701916963132ec7ad
strict-transport-security: max-age=0
timing-allow-origin: *

    Both requests return success responses, confirming that the sidecar proxy forwards outbound traffic to external services.

    Create a ServiceEntry

    When Outbound Traffic Policy is set to REGISTRY_ONLY, sidecar proxies block requests to unregistered external services. A ServiceEntry adds an external endpoint to the Istio service registry so that traffic to that endpoint is monitored and controlled by Istio, with support for routing rules, fault injection, and timeouts.

    Without a ServiceEntry, requests to external services are rejected:

    HTTP -- returns 502:

    curl -I http://www.aliyun.com/

    Expected output:

    HTTP/1.1 502 Bad Gateway
date: Mon, 07 Sep 2020 09:25:58 GMT
server: envoy
transfer-encoding: chunked

    HTTPS -- connection refused:

    curl -I https://www.aliyun.com/

    Expected output:

    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.aliyun.com:443

    Step 1: Create a ServiceEntry

    1. Log on to the ASM console.

    2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

    3. Click the name of the target ASM instance, or click Manage in the Actions column.

    4. In the left-side navigation pane, choose Cluster & Workload Management > External Service(ServiceEntry).

    5. Click Create from YAML.

    6. Select the target namespace, paste the following YAML into the code editor, and click Create.

    Set the hosts parameter based on your business requirements. This example uses www.aliyun.com:

    apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: aliyun-com-ext
spec:
  hosts:
  - 'www.aliyun.com'
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL
    FieldDescription
    hostsHostnames of the external service to register
    portsPorts and protocols exposed by the external service
    resolution: DNSResolves the host IP through DNS lookup
    location: MESH_EXTERNALMarks the service as external to the mesh

    Verify the ServiceEntry

    From a pod with sidecar proxy injection, confirm that the external service is reachable:

    HTTP request:

    curl -I http://www.aliyun.com/

    Expected output:

    HTTP/1.1 301 Moved Permanently
server: envoy
date: Mon, 07 Sep 2020 09:49:17 GMT
content-type: text/html
content-length: 239
location: https://www.aliyun.com/
eagleeye-traceid: 0be3e0a915994721583014504e7b31
timing-allow-origin: *
x-envoy-upstream-service-time: 66

    HTTPS request:

    curl -I https://www.aliyun.com/

    Expected output:

    HTTP/2 200
server: Tengine
date: Mon, 07 Sep 2020 09:49:31 GMT
content-type: text/html; charset=utf-8
vary: Accept-Encoding
vary: Accept-Encoding
strict-transport-security: max-age=31536000
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-readtime: 1
eagleeye-traceid: 0be3e0b115994721709577294ed9e8
strict-transport-security: max-age=0
timing-allow-origin: *

    The x-envoy-upstream-service-time header confirms that traffic passes through the Envoy sidecar proxy.

    Step 2 (optional): Create a VirtualService for traffic management

    After registering the external service with a ServiceEntry, create a VirtualService to apply routing rules such as fault injection, retries, or timeouts.

    The following example injects a 5-second delay into every request to www.aliyun.com:

    1. In the ASM console, navigate to the target ASM instance.

    2. In the left-side navigation pane, choose Traffic Management Center > VirtualService.

    3. Click Create from YAML.

    4. Select the target namespace, paste the following YAML, and click Create.

    apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: aliyun-com-ext
spec:
  hosts:
    - 'www.aliyun.com'
  http:
  - fault:
      delay:
        percent: 100
        fixedDelay: 5s
    route:
      - destination:
          host: www.aliyun.com
        weight: 100

    Verify the routing rule

    Measure the response time to confirm the 5-second delay:

    time curl -o /dev/null -s -w "%{http_code}\n" http://www.aliyun.com/

    Expected output:

    301
real  0m 5.07s
user  0m 0.00s
sys   0m 0.00s

    The real value of approximately 5 seconds confirms that the fault injection rule is active.

    Scope sidecar interception by CIDR block

    Instead of applying sidecar interception to all outbound traffic, scope it to specific CIDR blocks. Traffic destined for addresses outside the specified ranges bypasses the sidecar proxy entirely and routes directly to the destination.

    You can set the Addresses to Which External Access Is Redirected to Sidecar Proxy parameter to the service CIDR block of the Kubernetes clusters on the data plane of the ASM instance. This way, access to destination services in the Kubernetes clusters is intercepted by the sidecar proxy. Access to destination services outside the Kubernetes clusters bypasses the sidecar proxy.

    Procedure

    1. Log on to the ASM console.

    2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

    3. Click the name of the target ASM instance, or click Manage in the Actions column.

    4. In the left-side navigation pane, choose Dataplane Component Management > Sidecar Proxy Setting.

    5. On the global tab, click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

    6. In the Addresses to Which External Access Is Redirected to Sidecar Proxy field, enter the CIDR block to intercept, and then click Update Settings.

    Note

    The default value is *, which means all outbound traffic is intercepted. You can enter a CIDR block based on your business requirements. Generally, you can enter the service CIDR block of the Kubernetes clusters on the data plane of the ASM instance.

    Alternatively, enter a CIDR block in the Addresses to Which External Access Is Not Redirected to Sidecar Proxy field. Traffic to all addresses except the specified range is then intercepted by the sidecar proxy.