Control access to external services using an authorization policy - Alibaba Cloud Service Mesh

Sidecar proxies and egress gateways in Service Mesh (ASM) enforce fine-grained, identity-based egress control that Kubernetes NetworkPolicy cannot provide. By routing outbound traffic through an egress gateway and applying a DENY authorization policy, you can block HTTP requests from a specific namespace to an external endpoint based on namespace identity, service accounts, and other attributes.

This topic walks through a complete example: deny all HTTP traffic from services in the demo-frontend namespace to www.aliyun.com.

Use cases

Centralized egress auditing: Route all outbound traffic through a single egress gateway for logging and policy enforcement.
Namespace-scoped access control: Allow or deny access to external websites based on the source namespace or service identity.
Defense in depth: Layer application-level authorization on top of Kubernetes NetworkPolicy for zero-trust egress security.

How it works

Traffic flows through three components:

Sidecar proxy -- Intercepts outbound requests from workloads and forwards them to the egress gateway.
Egress gateway -- Serves as the centralized exit point where authorization policies are evaluated.
Authorization policy -- A DENY rule on the egress gateway that blocks requests originating from the demo-frontend namespace.

Workload (demo-frontend) --> Sidecar proxy --> Egress gateway --> External website
                                                    |
                                          Authorization policy
                                            (DENY applied here)

Prerequisites

Before you begin, make sure that you have:

A cluster added to the ASM instance. For more information, see Add a cluster to an ASM instance
A namespace named demo-frontend with automatic sidecar proxy injection enabled. For more information, see Manage global namespaces

Step 1: Deploy a test service

Deploy a sleep service in the demo-frontend namespace as a test workload for verifying egress traffic control.

Get the kubeconfig file and connect to the cluster with kubectl. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Create a file named sleep.yaml with the following content:

sleep.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true

Apply the file:

   kubectl apply -f sleep.yaml -n demo-frontend

Verify that a sidecar proxy is injected into the sleep pod:
1. Log on to the ACK console. In the left-side navigation pane, click Clusters.
2. On the Clusters page, click the name of the target cluster. In the left-side navigation pane, choose Workloads > Pods.
3. On the Pods page, select demo-frontend from the Namespace drop-down list and click the pod name of the sleep service.
4. On the Container tab, confirm that a container named istio-proxy appears. This confirms that the sidecar proxy was injected.

Step 2: Create an egress gateway

An egress gateway centralizes outbound traffic so that authorization policies can control which namespaces or services reach external endpoints.

Create an egress gateway named egressgateway. For instructions, see Create an egress gateway.

Step 3: Restrict outbound traffic to registered services only

By default, services in an ASM instance can access all external endpoints. To enforce egress control, switch the outbound traffic policy to REGISTRY_ONLY. After this change, only external services registered as service entries are accessible.

Set the outbound traffic policy

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Dataplane Component Management > Sidecar Proxy Setting.
On the global tab, click Outbound Traffic Policy, set the Outbound Traffic Policy parameter to REGISTEY_ONLY, and then click Update Settings.

Register the external website as a service entry

On the details page of the ASM instance, choose Cluster & Workload Management > External Service(ServiceEntry) in the left-side navigation pane. Click Create from YAML.
Select istio-system from the Namespace drop-down list and paste the following YAML:
The resolution field must be set to DNS. If set to NONE, the gateway routes traffic back to itself in an infinite loop because the destination IP matches the gateway's own service IP. With DNS resolution, the gateway resolves the external hostname to an IP address and forwards traffic to that address.
```
   apiVersion: networking.istio.io/v1beta1
   kind: ServiceEntry
   metadata:
     name: aliyuncom-ext
     namespace: istio-system
   spec:
     hosts:
       - www.aliyun.com
     location: MESH_EXTERNAL
     ports:
       - name: http
         number: 80
         protocol: HTTP
       - name: tls
         number: 443
         protocol: TLS
     resolution: DNS
```
Click Create.

Verify external access

Before proceeding, confirm that the sleep service can reach www.aliyun.com through the service entry:

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, click the cluster name. In the left-side navigation pane, choose Workloads > Pods.
On the Pods page, select demo-frontend from the Namespace drop-down list. Find the sleep pod and click Terminal > sleep in the Actions column.
Run the following command: A 301 response confirms that the service entry is working and the external website is reachable.
```
   curl -I http://www.aliyun.com
```

Step 4: Route traffic through the egress gateway

Create an Istio gateway, a destination rule, and a virtual service to route traffic from the demo-frontend namespace through the egress gateway to www.aliyun.com.

Create an Istio gateway

Create an Istio gateway in the istio-system namespace. For more information, see Manage Istio gateways.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTPS
      tls:
        mode: ISTIO_MUTUAL
      hosts:
        - '*'

The mode field is set to ISTIO_MUTUAL, which enables mutual Transport Layer Security (mTLS). Services in the mesh must complete mTLS authentication before sending traffic through the egress gateway.

Create a destination rule

Create a destination rule in the demo-frontend namespace. For more information, see Manage destination rules.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: demo-frontend
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
    - name: target-egress-gateway-mTLS
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
        tls:
          mode: ISTIO_MUTUAL

This destination rule applies mTLS to traffic from the demo-frontend namespace to the egress gateway.

Create a virtual service

Create a virtual service in the demo-frontend namespace. For more information, see Manage virtual services.

Virtual service YAML

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: demo-frontend
spec:
  exportTo:
    - istio-system
    - demo-frontend
  gateways:
    - mesh
    - istio-system/istio-egressgateway
  hosts:
    - www.aliyun.com
  http:
    - match:
        - gateways:
            - mesh
          port: 80
      route:
        - destination:
            host: istio-egressgateway.istio-system.svc.cluster.local
            port:
              number: 80
            subset: target-egress-gateway-mTLS
          weight: 100
    - match:
        - gateways:
            - istio-system/istio-egressgateway
          port: 80
      route:
        - destination:
            host: www.aliyun.com
            port:
              number: 80
          weight: 100

The http section defines two matching rules that form a two-hop routing path:

Rule	Gateway	Purpose
First	`mesh`	Sidecar proxies in `demo-frontend` intercept requests to `www.aliyun.com` and forward them to the egress gateway
Second	`istio-system/istio-egressgateway`	The egress gateway forwards traffic to the external endpoint (`www.aliyun.com`)

Step 5: Create an authorization policy

Apply a DENY authorization policy on the egress gateway to block all traffic from the demo-frontend namespace.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > AuthorizationPolicy. Click Create.

On the Create page, configure the following parameters:

Parameter	Value
Name	A name for the authorization policy
Policy Type	DENY
ASM Gateway	On the Gateway Scope tab, select egressgateway
Request Matching Rules	In the Add Request Source section, turn on Namespaces and set the value to `demo-frontend`

Click Create.

When multiple authorization policies target the same workload, Istio evaluates them in this order: CUSTOM > DENY > ALLOW. A request that matches a DENY policy is rejected regardless of any ALLOW policies. If no ALLOW policies exist, all non-denied requests are permitted by default.

Step 6: Verify the authorization policy

Confirm that services in the demo-frontend namespace can no longer access www.aliyun.com.

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster. In the left-side navigation pane, choose Workloads > Pods.
On the Pods page, select demo-frontend from the Namespace drop-down list. Find the pod name of the sleep service and click Terminal > sleep in the Actions column.
Run the following command: Expected output: The 403 Forbidden response confirms that the authorization policy blocks egress traffic from the demo-frontend namespace to www.aliyun.com. The server: envoy header confirms enforcement by the egress gateway's Envoy proxy.
```
   curl -I http://www.aliyun.com
```
```
   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Thu, 12 Oct 2023 07:14:09 GMT
   server: envoy
   x-envoy-upstream-service-time: 4
```

Security considerations

Authorization policies enforce egress control through sidecar proxies and the egress gateway. Be aware of the following limitations:

Sidecar bypass: If a workload bypasses its sidecar proxy (for example, a privileged pod without sidecar injection), it can access external services directly without traversing the egress gateway. The authorization policy does not apply to bypassed traffic.
Complementary measures: To prevent traffic from leaving the mesh without passing through the egress gateway, add enforcement at the infrastructure level. Use Kubernetes NetworkPolicy objects or firewall rules to deny all outbound traffic that does not originate from the egress gateway.

Alibaba Cloud Service Mesh:Deny egress traffic from a namespace to an external website