Create egress gateway

Egress traffic

Traffic that’s outbound from a pod that has an Istio sidecar also passes through that sidecar’s container, (more precisely, through Envoy). Therefore, the accessibility of external services depends on the configuration of that Envoy proxy.

By default, Istio configures the Envoy proxy to enable requests for unknown services. Although this provides a convenient way of getting started with Istio, it’s generally a good idea to put stricter controls in place.

Allow only registered access

You can configure Service Mesh Manager to permit access only to specific external services. For details, see External Services.

Egress gateway

Egress gateways define an exit point from your Istio mesh for outgoing traffic. Egress gateways also allow you to apply Istio features on the traffic that exits the mesh, for example monitoring, routing rules, or retries.

Why do you need egress gateways? For example:

• Your organization requires some, or all, outbound traffic to go through dedicated nodes. These nodes could be separated from the rest of the nodes for the purposes of monitoring and policy enforcement.
• The application nodes of a cluster don’t have public IPs, so the in-mesh services that run on them cannot access the internet directly. Allocating public IPs to the egress gateway nodes and routing egress traffic through the gateway allows for controlled access to external services.

Create egress gateway

To create an egress gateway from the command line and route egress traffic through it, complete the following steps. Alternatively, you can create an egress gateway using the dashboard.

Note: The YAML samples work with the Service Mesh Manager demo application. Adjust their parameters (for example, namespace, service name, and so on) as needed for your environment.

1. Create an egress gateway using the IstioMeshGateway resource. For details on the IstioMeshGateway resource, see the IstioMeshGateway CR reference.

   CAUTION:

   By the default, the IstioMeshGateway pod is running without root privileges, therefore it cannot use ports under 1024. Either use ports above 1024 as targetports (for example, 8080 instead of 80) or run the gateway pod with root privileges by setting spec.runAsRoot: true in the IstioMeshGateway custom resource.

   For testing, you can download and apply the following resource to create a new egress gateway deployment and a corresponding service in the smm-demo namespace.

   kubectl apply -f egress-meshgateway.yaml
   

   Expected output:

   istiomeshgateway.servicemesh.cisco.com/egress-demo created
   

2. Create a Gateway resource for the egress gateway. The Gateway resource connects the Istio configuration resources and the deployment of a matching gateway. Apply the following Gateway resource to configure the outbound port (80 in the previous example) on the egress gateway that you have defined in the previous step.

   kubectl apply -f egress-gateway.yaml
   

   Expected output:

   gateway.networking.istio.io/egress-demo created
   

3. Define a VirtualService resource to direct traffic from the sidecars to the egress gateway.

   Apply the following VirtualService to direct traffic from the sidecars to the egress gateway, and also from the egress gateway to the external service. Edit the VirtualService to match the external service you want to permit access to.

   kubectl apply -f egress-virtualservice.yaml
   

   Expected output:

   virtualservice.networking.istio.io/httpbin-egress created
   

4. Test access to the external service.

   If you have installed the Service Mesh Manager demo application and used the examples in the previous steps, you can run the following command to start requests from the notifications-v1 workload to the external http-bin service:

   kubectl -n smm-demo set env deployment/notifications-v1 'REQUESTS=http://httpbin.org/get#1'
   

   • If everything is set up correctly, the new egress gateway appears on the MENU > GATEWAYS page.
   • If there is egress traffic, the gateway appears on the MENU > GATEWAYS page (make sure to select the relevant namespace). Note that the traffic from the gateway to the external service is visible only if you create a ServiceEntry resource for the external service.

5. If needed, permit access only to specific external services. For details, see External Services.

Create egress gateway using dashboard

1. To create an egress gateway from Calisti dashboard, navigate to MENU > GATEWAYS. Click CREATE NEW. An interface to select the Egress gateway resource template opens.

   

   

2. Select Egress in the Template dropdown.

3. Here, you can edit the egress gateway resource. To validate the correctness of the YAML resource, click Validate . For details on the IstioMeshGateway resource, see the IstioMeshGateway CR reference.

4. Once the YAML file is validated and there are no errors, to create the egress gateway, click Create.

Edit egress gateway using dashboard

1. To edit a particular egress gateway in your service mesh, navigate to MENU > GATEWAYS. Click the Edit icon at the end of the row of the gateway you want to edit.

2. Edit the selected gateway YAML, and validate the YAML. For details on the IstioMeshGateway resource, see the IstioMeshGateway CR reference.

3. To apply the changes to the YAML, click Apply.

Delete egress gateway using dashboard

1. To delete a particular egress gateway in your service mesh, navigate to MENU > GATEWAYS. Click the Delete icon at the end of the row of the gateway you want to delete.

   

2. If you are absolutely sure that you want to delete the selected egress gateway, click Delete on the pop-up.

   CAUTION:

   Deleting the resource is irreversible and cannot be undone, as Calisti doesn’t store the old resource files.

IstioMeshGateway CR reference

This section describes the fields of the IstioMeshGateway custom resource.

apiVersion (string)

Must be servicemesh.cisco.com/v1alpha1

kind (string)

Must be IstioMeshGateway

spec (object)

The configuration and parameters of the IstioMeshGateway.

spec.type (string, required)

Type of the mesh gateway. Ingress gateways define an entry point into your Istio mesh for incoming traffic, while egress gateways define an exit point from your Istio mesh for outgoing traffic. Possible values:

• ingress
• egress

spec.istioControlPlane (object, required)

Specifies the istiocontrolplane cr the istio-proxy connects to by a namespaced name. When upgrading to a new Istio version (thus to a new control plane), this should be upgraded.

For example:

spec:
  istioControlPlane:
    name: cp-v115x
    namespace: istio-system

spec.deployment (object)

Configuration options for the Kubernetes istio-proxy deployment. Metadata like labels and annotations can be set here for the deployment or pods as well, in spec.deployment.metadata.annotations or spec.deployment.podMetadata.annotations.

spec.service (object, required)

Configuration options for the Kubernetes service. Annotations can be set here as well as in spec.service.metadata.annotations, they are often useful in cloud loadbalancer cases, for example to specify some configuration for AWS.

Example for Google Cloud Engine (GKE):

This example shows how to create an internal load balancer with a static ip address. The first step is to reserve a static ip address that can then be used by the load balancer.

More info about how to reserve a static internal ip address can be found at: Reserving a static internal IP address

More annotations and their description are available here: LoadBalancer Service parameters

IstioMeshGateway modifications:

  service:
    ports:
      - name: tcp-status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        protocol: TCP
        targetPort: 8080
    type: LoadBalancer
    loadBalancerIP: "10.100.100.100"
    metadata:
      annotations:
        networking.gke.io/load-balancer-type: "Internal"

Gateway modifications:

spec:
  selector:
    gateway-name: demo-gw
    gateway-type: ingress
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

VirtualService modifications:

  spec:
  hosts:
  - "*"
  gateways:
  - echo 
  http:
  - route:
    - destination:
        port:
          number: 80
        host: echo.default.svc.cluster.local

Example for Azure Kubernetes Service (AKS): This example shows how to modify the TCP idle timeout for a loadbalancer.

By default, it’s set to 4 minutes. If a period of inactivity is longer than the timeout value, there’s no guarantee that the TCP or HTTP session is maintained between the client and your cloud service.

More annotations and their description are available here: Azure LoadBalancer annotations

IstioMeshGateway modifications:

  service:
    ports:
      - name: tcp-status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        protocol: TCP
        targetPort: 8080
    type: LoadBalancer
    metadata:
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout: "10"

Example for Amazon Web Services (AWS): This example shows how to create a load balancer to specify which nodes to include in the target group registration for instance target type.

More annotations and their description are available here: AWS Load Balancer Controller Annotations

IstioMeshGateway modifications:

  service:
    ports:
      - name: tcp-status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        protocol: TCP
        targetPort: 8080
    type: LoadBalancer
    metadata:
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: k8s-app=echo

spec.runAsRoot (true | false)

Whether to run the gateway in a privileged container. If not running as root, only ports higher than 1024 can be opened on the container. Default value: false