Wallarm Filter for Istio Ingress¶

Wallarm provides a filter for securing APIs managed by Istio to analyze traffic in-line. You deploy the Wallarm node externally and apply the Wallarm-provided configuration in the Envoy settings to route traffic to the Wallarm node for analysis via the gRPC-based external processing filter.

OOB mode (mirrored traffic)

You can also use Wallarm filter for Istio to analyze traffic out-of-band (OOB) by setting the observability_mode Envoy parameter described here.

Use cases¶

Among all supported Wallarm deployment options, this is the optimal choice for securing in real time APIs managed by Istio running with Envoy proxy.

Limitations¶

Custom blocking page and code setup

Requirements¶

To proceed with the deployment, ensure that you meet the following requirements:

Understanding of Istio technologies
Istio with Envoy proxy managing API traffic

Deployment¶

1. Deploy a Wallarm Node¶

The Wallarm node is a core component of the Wallarm platform that you need to deploy. It inspects incoming traffic, detects malicious activities, and can be configured to mitigate threats.

Choose an artifact for a self-hosted node deployment and follow the instructions attached for the envoy-external-filter mode:

All-in-one installer for Linux infrastructures on bare metal or VMs
Docker image for environments that use containerized deployments
Helm chart for infrastructures utilizing Kubernetes

2. Configure Envoy to proxy traffic to the Wallarm node¶

In your envoy.yaml → http_filters section, configure the external processing filter for sending requests and responses to the external Wallarm Node for analysis. For this, use the following template:

...

http_filters:
- name: ext_proc
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor
    grpc_service:
      envoy_grpc:
        cluster_name: wallarm_cluster
    processing_mode:
      request_body_mode: STREAMED
      response_body_mode: STREAMED
    request_attributes: ["request.id", "request.time", "source.address"]

In your envoy.yaml → clusters section, configure the Wallarm cluster used to forward data to the Wallarm Node. For this, use the following template:

clusters:
- ...
- name: wallarm_cluster
  connect_timeout: 30s
  load_assignment:
    cluster_name: wallarm_cluster
    endpoints: # endpoint of the Wallarm Node
    - lb_endpoints:
      - endpoint:
          address:
            socket_address:
              address: 127.0.0.1
              port_value: 5080
  http2_protocol_options: {} # must be set for enabling http2
  transport_socket:
    name: envoy.transport_sockets.tls
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
      common_tls_context:
        validation_context:
          trusted_ca:
            filename: /path/to/node-ca.pem # CA that issued the certificate used by the Node instance

Avoiding possible 500 errors

To avoid possible 500 errors when problems with the external filter occur, you can add the failure_mode_allow parameter into configuration.

Testing¶

To test the functionality of the deployed filter, follow these steps:

Send the request with the test Path Traversal attack to the Istio Gateway:
```
curl https://<ISTIO_GATEWAY_IP>/etc/passwd
```
Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.