envoyproxy/gateway

Summary I was tuning response compression on my Gateway and noticed that BackendTrafficPolicy.spec.compressor only exposes minContentLength. The per-algorithm config structs BrotliCompressor, GzipCompressor, and ZstdCompressor are empty Go structs, so I can't set compression level/quality, strategy, window size, etc. through the CRD. I had to fall back to EnvoyPatchPolicy to tune anything beyond the defaults. Current state In api/v1alpha1/compression_types.go: type GzipCompressor struct{} type BrotliCompressor struct{} type ZstdCompressor struct{} The only exposed tuning knob is Compression.minContentLength: type Compression struct { Type CompressorType `json:"type"` Brotli *BrotliCompressor `json:"brotli,omitempty"` Gzip *GzipCompressor `json:"gzip,omitempty"` Zstd *ZstdCompressor `json:"zstd,omitempty"` MinContentLength *resource.Quantity `json:"minContentLength,omitempty"` } So the underlying Envoy compre

Description: LocalWasmModuleSource.Path (from #9530) documents an absolute path and validates Pattern=^/.* plus MinLength and MaxLength. LocalDynamicModuleSource.Path documents the same absolute-path requirement but only validates MinLength=1 and MaxLength=4096. A relative path such as foo.so is accepted by the API. Other API path fields often use only MinLength. Raised in review on #9530: #9530 (comment) Pick one rule and apply it to both fields: Add Pattern=^/.* to LocalDynamicModuleSource.Path, so both local module paths must start with /. Drop the pattern from LocalWasmModuleSource.Path and keep length-only validation, matching most other path fields. I would pick 1. The docs already say absolute path. The API should reject a relative path. [optional Relevant Links:] #9530 api/v1alpha1/wasm_types.go (LocalWasmModuleSource) api/v1alpha1/dynamic_module_types.go (LocalDynamicModuleSource)

Description When creating a Gateway resource with a name longer than 63 characters, Envoy Gateway fails to create the corresponding ServiceAccount resource (and potentially other derived infrastructure resources). While resource naming truncation/hashing mechanisms exist in some parts of the codebase, Envoy Gateway attaches the un-truncated Gateway name directly to the gateway.envoyproxy.io/owning-gateway-name label value on the generated ServiceAccount . This triggers a Kubernetes API Server validation error, as Kubernetes strict label value rules enforce a maximum limit of 63 characters. Steps to Reproduce Deploy Envoy Gateway (tested on v1.7.4). Create a Gateway resource with a name exceeding 63 characters (e.g., 64+ characters long): apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: this-is-an-extremely-long-gateway-name-that-definitely-exceeds-sixty-three-characters namespace: default spec: gatewayClassName: envoy-gateway listeners: - name: http

Envoy's RBAC HTTP filter supports evaluating policies in "shadow" mode via shadow_rules. In this mode, Envoy evaluates policies against live traffic and emits metrics (shadow_allowed, shadow_denied) and dynamic metadata (shadow_engine_result, shadow_effective_policy_id) without actively blocking or rejecting client requests. Currently, Envoy Gateway's SecurityPolicy CRD translates spec.authorization exclusively into active enforcement (rules). There is no native configuration to evaluate RBAC policies in shadow / audit mode. Configuring shadow rules currently requires resorting to EnvoyPatchPolicy. First-class support for RBAC shadow mode directly in SecurityPolicy would provide a safer and native rollout path. Potential Solution Add an optional mode field to SecurityPolicy.spec.authorization: apiVersion: gateway.envoyproxy.io/v1alpha1 kind: SecurityPolicy metadata: name: test-rbac spec: targetRef: group: gateway.networking.k8s.io kind: HTTPRoute name: backend-route a

Description SecurityPolicy authorization rules with clientIPGeoLocations currently reject the trustedCIDRs client IP detection mode. validateAuthorizationGeoIP returns: authorization clientIPGeoLocations does not support ClientIPDetection.XForwardedFor.TrustedCIDRs (internal/gatewayapi/securitypolicy.go, L3134 on current main.) The supported modes are directSourceIP, xForwardedFor.numTrustedHops and customHeader. This is a feature request to also support xForwardedFor.trustedCIDRs. Use case Internet-facing gateway with: a GeoIP authorization policy (country blocklist), and a client mix of direct clients and clients behind trusted CDNs (Cloudflare, Fastly). None of the supported detection modes gives the GeoIP filter the real end-user IP for that mix: directSourceIP geolocates the CDN edge for proxied traffic, so the country rules do not apply to the end user. xForwardedFor.numTrustedHops cannot express a mixed topology: direct and CDN-fronted traffic have different hop counts, and