Kyma

Appearance

Use the XFF Header to Configure IP-Based Access to a Workload ​

Expose your workload and configure IP-based access using the X-Forwarded-For (XFF) header. This helps to enhance security by ensuring that only trusted IPs can interact with your application.

Prerequisites ​

  • You have the Istio and API Gateway modules added.

  • You have a deployed workload.

  • To use CLI instructions, you must install kubectl and curl. Alternatively, you can use Kyma dashboard.

  • You have set up your custom domain. Alternatively, you can use the default domain of your Kyma cluster and the default Gateway kyma-system/kyma-gateway.

    NOTE

    Because the default Kyma domain is a wildcard domain, which uses a simple TLS Gateway, it is recommended that you set up your custom domain for use in a production environment.

    TIP

    To learn what the default domain of your Kyma cluster is, run kubectl get gateway -n kyma-system kyma-gateway -o jsonpath='{.spec.servers[0].hosts}'.

Context ​

The XFF header is a standard HTTP header that conveys the client IP address and the chain of intermediary proxies that the request traverses to reach the Istio service mesh. This is particularly useful when an application must be provided with the client IP address of an originating request, for example, for access control.

However, there are some technical limitations when using the XFF header. The header might not include all IP addresses if an intermediary proxy does not support modifying the header. Due to technical limitations of AWS Classic ELBs, when using an IPv4 connection, the header does not include the public IP of the load balancer in front of Istio Ingress Gateway. Moreover, Istio Ingress Gateway's Envoy does not append the private IP address of the load balancer to the XFF header, effectively removing this information from the request. For more information on XFF, see the IETF’s RFC documentation and Envoy documentation.

To use the XFF header, you must configure the corresponding settings in the Istio custom resource (CR). Then, expose your workload using a VirtualService and create an AuthorizationPolicy resource with allowed IP addresses specified in the remoteIpBlocks field. To learn how to do this, follow the procedure.

Procedure ​

Results ​

You have configured the XFF header in the Istio CR and exposed your workload to the internet. Access to the workload is limited to the IP addresses that you have specified.