Trusted Proxy

Configure trusted proxy settings for accurate client IP identification behind load balancers and CDNs

When Jitera runs behind a reverse proxy, load balancer, or CDN, the application sees the proxy’s IP address instead of the real client IP. This affects security features (rate limiting, IP blocking), audit logging, and compliance. Trusted proxy configuration tells Jitera which proxy IP addresses to trust, allowing it to read the real client IP from the X-Forwarded-For header.

---

Two-Layer Trust Chain

Client IP preservation requires trust configuration at two layers of the request path:

Layer	Setting	Location
Kong ingress	kong.env.trusted_ips	Helm values
Jitera application	proxies.yaml + ENABLE_PROXY_FROM_X_HEADER	charts/jitera/extra_config/ + Helm values

Narrow both to the CIDR of the preceding hop in production.

Kong Ingress Trusted IPs

The chart ships with kong.env.trusted_ips: "0.0.0.0/0,::/0", which makes Kong accept x-real-ip / X-Forwarded-For headers from any source. For production, narrow this to the CIDR of the load balancer sitting in front of Kong:

kong:
  env:
    trusted_ips: "10.0.0.0/16"     # your LB subnet CIDR (example)
    real_ip_header: "x-real-ip"    # chart default

Use the VPC CIDR or LB-subnet CIDR as appropriate for your topology.

---

Configuration Methods

Method	Security	Use Case
Explicit IP trust list	High	Production — only specific proxy IPs are trusted
X-Forwarded-For header trust	Medium	Development/testing — trusts the header from any source

Explicit IP Trust List (Recommended)

Define exactly which IP addresses are allowed to provide client IP information by creating a proxy configuration file.

Step 1: Create charts/jitera/extra_config/proxies.yaml:

trusted_proxies:
  - 10.0.0.0/8        # Kubernetes pod/service networks
  - 172.16.0.0/12     # Private network range
  - 192.168.0.0/16    # Private network range
  # Add your load balancer or CDN IP ranges below:
  # - 203.0.113.0/24  # Example: CDN IP range
  # - 198.51.100.5    # Example: specific load balancer IP

Step 2: Disable header-only trust:

automation:
  env:
    ENABLE_PROXY_FROM_X_HEADER: false

The application will only accept client IP information from the X-Forwarded-For header when the request originates from an IP address listed in proxies.yaml.

The proxies.yaml file ships empty by default. You must add your infrastructure’s proxy IP ranges for trusted proxy to take effect.

X-Forwarded-For Header Trust

For development or fully controlled internal networks, you can enable header-based trust without an explicit IP list:

automation:
  env:
    ENABLE_PROXY_FROM_X_HEADER: true

When ENABLE_PROXY_FROM_X_HEADER is true, any client can spoof their IP address by setting the X-Forwarded-For header. Do not use this in production environments with external traffic.

---

IP Address Formats

proxies.yaml supports the following formats:

Format	Example	Use Case
IPv4 single	192.168.1.1	Specific load balancer
IPv4 CIDR	10.0.0.0/8	Network range
IPv6 single	2001:db8::1	Specific IPv6 proxy
IPv6 CIDR	2001:db8::/32	IPv6 network range

---

Examples by Infrastructure

AWS (EKS)

AWS Application Load Balancers operate within your VPC’s private IP ranges:

trusted_proxies:
  - 10.0.0.0/8       # VPC internal range (adjust to your VPC CIDR)
  - 172.16.0.0/12    # Additional private range if used

Azure (AKS)

Azure load balancers and Azure Front Door use Azure-managed IP ranges. For Azure Front Door, see the Azure IP ranges and service tags for current addresses.

trusted_proxies:
  - 10.0.0.0/8       # AKS virtual network range (adjust to your VNet CIDR)
  - 168.63.129.16/32  # Azure health probe

On-Premises

For self-managed clusters, include your pod/service network CIDRs and any external load balancer IPs:

trusted_proxies:
  - 10.244.0.0/16    # Default pod network (adjust for your cluster)
  - 10.96.0.0/12     # Default service network
  - 192.168.1.100    # Example: MetalLB load balancer IP

Cloudflare CDN

If using Cloudflare in front of your cluster, add their public IP ranges. These ranges change periodically — verify at cloudflare.com/ips.

trusted_proxies:
  - 173.245.48.0/20
  - 103.21.244.0/22
  - 103.22.200.0/22
  - 103.31.4.0/22
  - 141.101.64.0/18
  - 108.162.192.0/18
  - 190.93.240.0/20
  # See cloudflare.com/ips for the full current list

---

Helm Values Reference

Parameter	Type	Default	Description
automation.env.ENABLE_PROXY_FROM_X_HEADER	boolean	false	Trust X-Forwarded-For header from any source. Set to true only for development.

The trusted proxy IP list is defined in charts/jitera/extra_config/proxies.yaml (not a Helm value). For the complete Helm configuration reference, see Automation Environment Variables.

---

Verification

After configuring trusted proxies:

# Check the ENABLE_PROXY_FROM_X_HEADER setting
kubectl exec -it deploy/jitera-automation-rails -n jitera -- \
  env | grep ENABLE_PROXY

# Verify proxies.yaml is mounted (if using explicit IP list)
kubectl exec -it deploy/jitera-automation-rails -n jitera -- \
  cat /app/config/proxies.yaml

To confirm client IP detection is working, check the audit logs or application logs for the correct client IP addresses after a request through your proxy.