When applications in a Service Mesh (ASM) instance need to communicate with external services, you can use an egress gateway to centrally manage all outbound traffic. After you configure an egress gateway, you can implement security control and routing of traffic to improve the security and observability of applications in the ASM instance.
Prerequisites
Automatic sidecar proxy injection is enabled. For more information, see Enable automatic sidecar proxy injection.
Procedure
Step 1: Deploy a sample application
Deploy a sleep application.
Create a sleep.yaml file that contains the following content:
Use kubectl to connect to the Container Service for Kubernetes (ACK) cluster based on the information in the kubeconfig file, and then run the following command to deploy the sleep application.
For more information about how to use kubectl to manage a cluster, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.
kubectl apply -f sleep.yaml
Run the following commands to access external services from the pod where the sleep application resides.
You can run the
kubectl get pod -n default
command to view the name of the pod where the sleep application resides.kubectl exec -it ${Name of the pod where the sleep application resides} -- /bin/sh curl aliyun.com -I
Sample output:
HTTP/1.1 301 Moved Permanently server: envoy date: Thu, 14 Dec 2023 03:05:41 GMT content-type: text/html content-length: 239 location: https://aliyun.com/ eagleeye-traceid: 0b57ff8717025231418255220e**** timing-allow-origin: * x-envoy-upstream-service-time: 69
If 301 is returned, it indicates that the applications in the ASM instance can access external services. In this example, an HTTP access request is initiated by default. The web server returns a 301 response to redirect the request.
NoteBy default, ASM uses the ALLOW_ANY policy to allow applications in an ASM instance to access all external services. In this case, you cannot implement permission control or use the observability capabilities provided by ASM. We recommend that you change the policy to REGISTRY_ONLY to allow applications in the ASM instance to access only specific external services, and that you use an egress gateway to route all the outbound traffic.
(Optional) Step 2: Set the policy for accessing external services to REGISTRY_ONLY
By default, ASM uses the ALLOW_ANY policy for accessing external services. We recommend that you change the policy to REGISTRY_ONLY. After you change the policy to REGISTRY_ONLY, sidecar proxies deny access to external hosts for which service entries are not defined in the ASM instance. This guarantees the security of applications in the ASM instance.
If you have changed the policy to REGISTRY_ONLY but have not created a service entry, access requests to external services are denied.
If you have not changed the policy to REGISTRY_ONLY or created a service entry, access requests to external services are allowed but they do not pass through the egress gateway.
Log on to the ASM console. In the left-side navigation pane, choose .
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose .
On the Sidecar Proxy Setting page, click the global tab, expand Outbound Traffic Policy, select REGISTRY_ONLY for Outbound Traffic Policy, and then click Update Settings.
Run the following commands to access external services from the pod where the sleep application resides:
kubectl exec -it ${Name of the pod where the sleep application resides} -- /bin/sh curl aliyun.com -I
Sample output:
HTTP/1.1 502 Bad Gateway date: Thu, 14 Dec 2023 03:08:46 GMT server: envoy transfer-encoding: chunked
A 502 error code is returned, indicating that the application in the ASM instance cannot access an external service that is not defined in the service registry of the ASM instance.
Step 3: Create a service entry to define an external service
You need to create a service entry to define an external service so that applications in the ASM instance can access the external service by using the egress gateway.
Log on to the ASM console. In the left-side navigation pane, choose .
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose . On the page that appears, click Create from YAML.
On the Create page, select the namespace in which the sleep application resides, select Access mesh external services for Template, configure a YAML file, and then click Create. The following YAML file provides an example.
apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: external-svc-http spec: hosts: - aliyun.com location: MESH_EXTERNAL ports: - number: 80 name: http protocol: HTTP resolution: DNS
Run the following command to access the external service from the pod where the sleep application resides:
kubectl exec -it ${Name of the pod where the sleep application resides} -- /bin/sh curl aliyun.com -I
If
301
is returned, it indicates that the application in the ASM instance can access the external service. The aliyun.com domain name is defined in the service registry of the ASM instance, and therefore applications in the ASM instance can access this external service. In this case, the pod where the sleep application resides directly sends access requests to the external service and the requests do not pass through the egress gateway.
Step 4: Use an egress gateway to route all the requests to access external services
You have defined the aliyun.com domain name in the service entry of the ASM instance. Therefore, you can configure a virtual service and Istio gateway to manage the traffic to aliyun.com.
Create an egress gateway and configure the HTTP protocol and port 80. For more information, see Create an egress gateway.
Create an Istio gateway and configure the related parameters as instructed in the following figure. For more information, see Manage Istio gateways.
Use the following YAML code to create a virtual service. For more information, see Manage virtual services.
Access the external service to verify the configuration.
Run the following commands to access the external service from the pod where the sleep application resides:
kubectl exec -it ${Name of the pod where the sleep application resides} -- /bin/sh curl aliyun.com -I
If 301 is returned, it indicates that the application in the ASM instance can access the external service. In this case, the application in the ASM instance does not directly access the external service from the pod where the application resides. Instead, the application accesses the external service through the egress gateway.
Run the following command to query access logs of the pod where the egress gateway resides.
NoteIf your egress gateway pod has multiple replicas, the access logs are generated in one of them. You must run this command on these pod replicas in sequence to find the access logs.
If you have enabled the access log feature for the egress gateway, you can log on to the Simple Log Service console to view access logs.
kubectl -n istio-system logs ${Name of the pod where the egress gateway resides} -c istio-proxy | grep aliyun.com | tail -n 1
Sample output:
{"trace_id":null,"upstream_host":"106.11.XXX.XX:80","downstream_remote_address":"10.34.0.140:47942","requested_server_name":null,"response_code":301,"upstream_service_time":"24","user_agent":"curl/7.86.0-DEV","path":"/","route_name":null,"bytes_sent":0,"response_flags":"-","upstream_local_address":"10.34.0.141:60388","duration":24,"upstream_cluster":"outbound|80||aliyun.com","upstream_transport_failure_reason":null,"authority":"aliyun.com","request_id":"55789d59-9b81-4e39-b64a-66baf44e****","protocol":"HTTP/1.1","bytes_received":0,"method":"HEAD","downstream_local_address":"10.34.0.141:80","start_time":"2022-11-30T08:03:01.315Z","istio_policy_status":null,"x_forwarded_for":"10.34.0.140"}
downstream_remote_address
indicates the IP address of the pod where the sleep application resides.After you complete the configurations, access requests to the specified external service pass through the egress gateway. You can use the observability and security capabilities provided by ASM to manage outbound traffic on the egress gateway in an efficient manner.
References
You can use the observability and security capabilities provided by ASM to manage outbound traffic more efficiently on your egress gateway. For more information, see Observability and Traffic security and dynamic certificate loading.
You can use ASMEgressTrafficPolicy CustomResourceDefinition (CRD) fields to customize how to manage outbound traffic by using an egress gateway. For more information, see Use an egress traffic policy to manage egress traffic.
For more information about the features of ASM gateways, see Overview of ASM gateways.