Configuring Envoy Proxy for Aqua Supply Chain Security Endpoints

Overview

Organizations routing Aqua Supply Chain Security and Workload Protection traffic through an Envoy proxy must configure filter chains, health checks, and TLS inspection correctly. Misconfigured Envoy deployments commonly fail Kubernetes readiness and liveness probes, preventing the proxy pod from starting.

This article explains how Kubernetes health probes interact with Envoy, how to configure filter chains for multiple Aqua SaaS endpoints, and Aqua API rate limits for proxied traffic.

Understanding Envoy Health Check Behavior

Kubernetes Probes vs. Envoy Health Check Filter

Kubernetes sends readiness and liveness probes directly to the Envoy pod:

https://<pod-IP>:8443/healthz

With header: x-envoy-livenessprobe: healthz

The Envoy envoy.filters.http.health_check filter handles /healthz requests when pass_through_mode is set to false. In this mode, the health check is answered locally by Envoy and not forwarded upstream to Aqua SaaS endpoints.

Aqua SaaS Endpoints Do Not Expose /healthz

Supply Chain Security and gateway endpoints do not provide a /healthz health check path:

Kubernetes probes must be handled locally by Envoy — not routed to upstream Aqua endpoints.

Problem Description

Symptoms

• Envoy pod fails readiness and liveness probes
• Pod describe shows errors:

```

Readiness probe failed: Get "https://<pod-IP>:8443/healthz": connection reset by peer

Liveness probe failed: Get "https://<pod-IP>:8443/healthz": connection reset by peer

```

• Envoy pod works when readiness and liveness probes are removed from the deployment
• Custom Envoy config routes traffic to Supply Chain Security URLs via SNI-based filter chains

Root Cause

When every filter_chain in the Envoy listener includes a filter_chain_match with server_names, Kubernetes probe requests to https://<pod-IP>:8443/healthz do not match any SNI-based filter chain. The pod IP is not a configured server name, so Envoy cannot route the health check request and the probe fails.

Solution

Step 1: Configure a Default Filter Chain

Ensure the last filter chain in the listener does not include a filter_chain_match block. This creates a default route that catches requests without a matching SNI — including Kubernetes health probe requests to the pod IP.

For the three or four Supply Chain endpoints, configure SNI-based filter_chain_match on the first filter chains. The final filter chain handles all unmatched traffic (including /healthz probes).

Step 2: Configure Health Check Filter

In the default filter chain, include the health check filter with pass_through_mode: false:

http_filters:
  - name: envoy.filters.http.health_check
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.health_check.v3.HealthCheck
      pass_through_mode: false
      headers:
        - name: ":path"
          exact_match: "/healthz"
        - name: "x-envoy-livenessprobe"
          exact_match: "healthz"
  - name: envoy.filters.http.router
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

Step 3: Retain Kubernetes Probe Configuration

Use the standard Aqua Helm probe configuration from aqua-helm values:

readinessProbe:
  httpGet:
    scheme: HTTPS
    path: /healthz
    httpHeaders:
      - name: x-envoy-livenessprobe
        value: healthz
    port: 8443
  initialDelaySeconds: 3
  periodSeconds: 10
livenessProbe:
  httpGet:
    scheme: HTTPS
    path: /healthz
    httpHeaders:
      - name: x-envoy-livenessprobe
        value: healthz
    port: 8443
  initialDelaySeconds: 10
  periodSeconds: 10

Step 4: Verify Pod Health

1. 1. Apply the updated Envoy configuration
2. 2. Confirm the pod reaches Running status with passing probes
3. 3. Test routing to each Supply Chain endpoint through the proxy
4. 4. Verify Workload Protection gateway traffic continues to function on a separate Envoy instance if applicable

Architecture: Dual Envoy Deployment

A common pattern uses separate Envoy instances for different traffic types:

Each instance requires the default filter chain pattern described above.

Aqua API Rate Limits

When routing traffic through a corporate proxy or NAT gateway, all requests may originate from a single source IP. Be aware of Aqua SaaS rate limits:

High-volume scanning or CI/CD traffic from a single egress IP may approach these limits. Monitor for HTTP 429 responses and plan egress IP distribution if needed.

Important Considerations

• The Aqua Envoy image is provided for on-premises deployments routing to Aqua SaaS gateways. Custom Envoy configurations for Supply Chain endpoints require independent validation.
• TLS Inspector (envoy.filters.listener.tls_inspector) can be used to route by SNI when a Network Load Balancer sits in front of Envoy pods.
• Removing envoy.filters.http.health_check entirely is possible but removes application-level health visibility; the default filter chain approach is preferred.
• Supply Chain SaaS endpoints do not support upstream health checking via /healthz.

Verification and Monitoring

1. 1. Confirm Envoy pod passes readiness and liveness probes (kubectl describe pod)
2. 2. Test HTTPS connectivity to each proxied Aqua endpoint
3. 3. Monitor Envoy access logs for routing errors
4. 4. Watch for rate limit responses (HTTP 429) under production traffic volumes

Platform Coverage

• Platform: Kubernetes (on-premises routing to Aqua SaaS)
• Component: Gateway / Envoy Proxy
• Aqua Version: 2022.4.x Helm chart and later

Summary

Related Resources

• Aqua Helm Chart — Envoy Configuration
• Envoy Health Check Filter Documentation
• Kubernetes Liveness and Readiness Probes