Service Mesh (ASM) provides flexible and efficient solutions for egress traffic management that ensure application security, observability, and reliability. This topic describes the egress traffic management features of ASM and the benefits of using an ASM egress gateway.
Rich egress traffic management capabilities
ASM provides rich features for managing Layer 7 egress traffic, which are related to traffic routing, observability, and security. You can configure the features as needed.
If an application directly initiates an HTTPS request, the corresponding sidecar proxy can only process the HTTPS request as normal TLS traffic, and Layer 7 features of ASM do not take effect. Therefore, make sure that the requests sent by your application are HTTP plaintext requests. ASM directly forwards the HTTP requests to external services or automatically converts HTTP requests into HTTPS requests and then sends them to external services based on your configurations.
Traffic routing
To access HTTP services outside a cluster, you configure the corresponding service entries in the service mesh. This lets you use advanced features in virtual services, such as egress traffic mirroring and egress traffic routing by ratio. If you access a service that uses the HTTPS protocol, you must also configure a DestinationRule. The traffic routing feature does not require an ASM egress gateway.
Egress traffic observation
For plaintext requests, you can observe egress traffic using logs, metrics, and tracing analysis without any additional configuration. If the request traffic must be encrypted, you only need to configure a service entry and a DestinationRule. When an application initiates a plaintext request, the sidecar automatically encrypts the traffic before forwarding it. This lets you use the full observability capabilities of the mesh. This feature does not require an ASM egress gateway.
Egress traffic authentication/authorization
ASM also provides robust authentication and authorization capabilities for egress traffic. You can implement advanced security features in ASM, such as verifying the JSON Web Tokens (JWTs) of egress traffic and restricting access from specific clients based on Layer 7 or Layer 4 request metadata. These features require an ASM egress gateway. For more information, see Security models for egress traffic.
Security models for egress traffic
For pure TCP traffic (non-HTTP and non-TLS traffic), you can use native Kubernetes network policies to enhance security.
Default action
The default action is ALLOW_ANY, which indicates that the sidecar proxy does not impose any restrictions on the egress traffic. In this case, the behavior of egress traffic is completely uncontrolled. The security level is the lowest.
REGISTRY_ONLY
If you enable REGISTRY_ONLY, applications can access only the services that are registered using service entries.
Because application owners have permission to change application pod configurations, they can use multiple methods to cause egress traffic to bypass the sidecar proxy. If a request bypasses the sidecar proxy, the access restrictions of REGISTRY_ONLY become invalid, and the application can access external services without restriction. Therefore, REGISTRY_ONLY is not considered a valid security policy.
Additionally, this solution can only restrict access to external services for workloads in a specified namespace. It cannot provide granular control for specific workloads.
REGISTRY_ONLY and egress gateway
The egress gateway can serve as an ideal security boundary. As a separate deployment, the egress gateway is fully controlled by the mesh administrator. The application owner cannot directly control the egress gateway or its security policies.
In addition, you must ensure that only the nodes where the egress gateway is deployed can access external services and that other nodes cannot. Application pods cannot directly access the internet. To successfully send traffic to an external service, the application owner must ensure that the application's egress traffic is processed by the sidecar proxy and then forwarded to the egress gateway.
After the traffic is transparently forwarded to the egress gateway:
You can configure authorization policies on the egress gateway to implement fine-grained authorization or implement custom authorization.
If the service that you want to access is an HTTPS service, you can configure an HTTP-to-HTTPS upgrade on the egress gateway. The egress gateway automatically manages HTTPS connections. It can multiplex HTTPS connections across workloads to improve performance.
Use with Cloud Firewall
When you use Cloud Firewall to strictly restrict the outbound traffic of a VPC or NAT Gateway, you must assign a fixed and predictable IP address range to the pods of the ASM egress gateway and add the IP address range to the whitelist in the firewall policy.
To achieve this, ensure that the egress gateway pods use an independent and exclusive IP address segment. In an Alibaba Cloud ACK cluster, you can use one of the following two methods:
Use Terway Container Network Interface (CNI) to assign fixed IP addresses to pods (Recommended).
If your ACK cluster uses the Terway network mode, you can use its native capabilities to assign fixed IP addresses to the egress gateway pods and associate them with an independent virtual switch and security group. This is the most direct and concise solution. For more information, see Configure a static IP address, a separate vSwitch, and a separate security group for each pod.
Use the host network (HostNetwork) to indirectly assign fixed IP addresses to pods.
If you cannot use the first method, you can follow these steps to indirectly assign the node's IP address to the egress gateway pod:
Create an exclusive node pool: Create a dedicated node pool for the egress gateway. Ensure that the IP address range of this node pool does not overlap with the IP address ranges of other application pods in the cluster. For more information, see Create and manage a node pool.
Add node taints: Add taints to all nodes in this node pool to prevent other pods from being scheduled to them.
Configure the egress gateway: Modify the deployment configuration of the egress gateway to:
Enable the host network mode (
hostNetwork: true).Add corresponding tolerations to match the taints of the dedicated node pool.
Configure affinity to ensure that pods are scheduled to this exclusive node pool.
After you complete these configurations, the egress gateway pod uses its node's IP address as the egress IP address. Then, you can add the IP address segment of the exclusive node pool to the Cloud Firewall whitelist.
References
You can use egress traffic policies provided by ASM to quickly configure traffic rules for using an egress gateway to access services outside a cluster. For more information, see Use an egress traffic policy to manage egress traffic.