Wallarm Filter for Istio Ingress¶

Wallarm provides a filter for securing APIs managed by Istio to analyze traffic in-line or out-of-band. 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¶

This is the optimal choice for securing in real time APIs managed by Istio running with Envoy proxy.

Limitations¶

When deploying the Wallarm service with the LoadBalancer type using the Helm chart, a trusted SSL/TLS certificate is required for the domain. Self-signed certificates are not yet supported.
Custom blocking page and blocking code configurations are not yet supported.
Rate limiting by the Wallarm rule is not supported.
Multitenancy is not supported yet.

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
AWS AMI for AWS infrastructures
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.