Service Mesh (ASM) provides a variety of flexible and efficient solutions for egress traffic management to ensure security, observability, and reliability of applications. This topic describes how to use egress gateways to manage egress traffic that accesses services outside a cluster and the security models for egress traffic.
Why is egress traffic management required?
ASM provides rich features for managing Layer 7 egress traffic, which are related to traffic routing, observability, and security. You can configure the features based on your business requirements.
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 services outside a cluster, you need to only configure the corresponding service entries in an ASM instance. Then, you can use advanced capabilities of virtual services, such as egress mirroring and egress traffic routing by ratio.
Egress traffic observation
If requests are sent in plaintext, you can observe the egress traffic by using logs, metric monitoring, and trace analysis, without the need to perform any operations. If requests are destined to an external service and the request traffic needs to be encrypted, you need to only configure a service entry and a destination rule. When an application sends plaintext requests, the sidecar proxy automatically encrypts the plaintext requests before forwarding them.
Security requirements
To access services outside a cluster, you can configure specific policies to specify the external services that are allowed to access, specify specific applications to access specific external services, and specify other fine-grained authentication methods. For more information, see Security models for egress traffic.
Security models for egress traffic
ASM provides three security models for egress traffic. You can select an appropriate solution based on your business requirements. For pure TCP traffic (non-HTTP and non-TLS traffic), we recommend that you use Kubernetes-native network policies to enhance its 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
When the Outbound Traffic Policy parameter is set to REGISTRY_ONLY, the pod can access only the services that are registered as service entries.
You may think that this solution uses sidecar proxies as trustable security boundaries. However, implementing security policies only on sidecar proxies is not secure. Application owners have permissions to change the configurations of application pods. Therefore, they can use multiple methods to enable egress traffic to bypass sidecar proxies. If egress traffic bypasses sidecar proxies, all security policies on the sidecar proxies become invalid. Therefore, ASM does not provide authorization policies that can be configured in the egress direction of sidecar proxies.
This solution can only enable workloads in the specified namespace to access external services. It cannot narrow the scope of control over specific workloads in a more granular manner, and cannot use the authorization policies provided by gateways.
REGISTRY_ONLY and egress gateway
The egress gateway can serve as an ideal security boundary. As a separate Deployment, the deployment behavior of the egress gateway is fully controlled by the ASM administrator. The application owner cannot directly control the egress gateway and its security policies.
In addition, the ASM administrator must make sure that only the nodes on which the egress gateway is deployed can access external services and that other nodes cannot access external services. Application pods cannot directly access the Internet. To sent traffic to an external service, you must make sure that the egress traffic of the application is successfully processed by the sidecar proxy and then forwarded to the egress gateway as expected.
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.
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.