Help Center/ Cloud Container Engine/ Best Practices/ Networking/ Obtaining the Client Source IP Address for a Container
Updated on 2024-07-04 GMT+08:00

Obtaining the Client Source IP Address for a Container

In containers, multiple types of proxy servers may exist between a client and the container servers. After an external request is forwarded for multiple times, the source IP address of the client cannot be transmitted to the containers. As a result, Services in the containers cannot obtain the real source IP addresses of the client.

Description

Figure 1 Obtaining the source IP addresses from the containers

Layer-7 forwarding:

Ingresses: If this access mode is used, the client's source IP address is saved in the X-Forwarded-For field of the HTTP header by default. No other configuration is required.

  • Huawei LoadBalancer Ingresses use ELB for Layer 7 network access between the Internet and internal network (in the same VPC) based on the ELB service.
  • The Nginx Ingresses implement Layer 7 network access based on nginx-ingress. The backend Service type can be either ClusterIP or NodePort.

Layer-4 forwarding:

  • LoadBalancer: Use ELB to achieve load balancing. You can manually enable the Transfer Client IP Address option for TCP and UDP listeners of shared load balancers. By default, the Transfer Client IP Address option is enabled for TCP and UDP listeners of dedicated load balancers. You do not need to manually enable it.
  • NodePort: The container port is mapped to the node port. If the cluster-level affinity is selected, access requests will be forwarded through the node and the client source IP address cannot be obtained. If the node-level affinity is selected, access requests will not be forwarded and the client source IP address can be obtained.

If Istio is used, you can obtain the source IP address by referring to How Do I Obtain the Actual Source IP Address of a Client After a Service Is Added into Istio?

Scenarios in Which Source IP Address Can Be Obtained

Due to network model differences, CCE does not allow obtaining source IP addresses in some scenarios, as listed in Table 1. "-" in the table indicates that this scenario does not exist.

Table 1 Scenarios in which source IP addresses can be obtained

Level-1 Category

Level-2 Category

Load Balancer Type

VPC and Container Tunnel Network Models

Cloud Native Network 2.0 Model (CCE Turbo Clusters)

Reference

Layer-7 forwarding (ingress)

ELB

Shared

Supported

Supported

ELB Ingress

Dedicated

Supported

Supported

Nginx (interconnected with the nginx-ingress add-on)

Shared

Supported

Not supported

Nginx Ingress

Dedicated

Supported

Supported

This function is enabled by default. No other configuration is required.

Layer-4 forwarding (Service)

LoadBalancer

Shared

Supported

Not supported (supported by workloads that use hostNetwork)

LoadBalancer

Dedicated

Supported

Supported

NodePort

-

Supported

Not supported (supported by workloads that use hostNetwork)

NodePort

ELB Ingress

For the ELB Ingresses (using HTTP- or HTTPS-compliant), the function of obtaining the source IP addresses of the client is enabled by default. No other operation is required.

The real IP address is placed in the X-Forwarded-For HTTP header field by the load balancer in the following format:

X-Forwarded-For: IP address of the client,Proxy server 1-IP address,Proxy server 2-IP address,...

If you use this method, the first IP address obtained is the IP address of the client.

Nginx Ingress

In the Cloud Native Network 2.0 model, source IP addresses cannot be obtained if a shared load balancer is used when an Ingress is interconnected with the nginx-ingress add-on. For details, see Scenarios in Which Source IP Address Can Be Obtained. To obtain the source IP, uninstall the nginx-ingress add-on and use a dedicated load balancer during reinstallation.

  • For an Nginx Ingress that uses a dedicated load balancer, transparent transmission of source IP addresses is enabled by default. This means that you can easily obtain the source IP address of the client without any additional configurations.
  • For an Nginx Ingress that uses a shared load balancer, perform the following steps to obtain the source IP address of the client:
  1. Take the Nginx workload as an example. Before configuring the source IP address, obtain the access logs. nginx-c99fd67bb-ghv4q indicates the pod name.

    kubectl logs nginx-c99fd67bb-ghv4q

    Information similar to the following is displayed:

    ...
    10.0.0.7 - - [17/Aug/2023:01:30:11 +0000] "GET / HTTP/1.1" 200 19 "http://114.114.114.114:9421/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" "100.125.**.**"

    100.125.**.** specifies the CIDR block of the load balancer, indicating that the traffic is forwarded through the load balancer.

  2. Go to the ELB console and enable the function of obtaining the client IP address of the listener corresponding to the load balancer. Transparent transmission of source IP addresses is enabled for dedicated load balancers by default. You do not need to manually enable this function.

    1. Log in to the ELB console.
    2. Click in the upper left corner of the management console and select a region and a project.
    3. Click Service List. Under Networking, click Elastic Load Balance.
    4. On the Load Balancers page, click the name of the load balancer.
    5. Click the Listeners tab, locate the row containing the target listener, and click Edit. If modification protection exists, disable the protection on the basic information page of the listener and try again.
    6. Enable Transfer Client IP Address.
      Figure 2 Enabling the function

  3. Access the workload again and view the new access log.

    ...
    10.0.0.7 - - [17/Aug/2023:02:43:11 +0000] "GET / HTTP/1.1" 304 0 "http://114.114.114.114:9421/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" "124.**.**.**"

    The source IP address of the client is obtained.

You can enable WAF for the load balancers used by Nginx Ingress Controllers in clusters, but different WAF modes will affect how Nginx Ingress Controllers obtain the real client IP addresses.

  • Load balancer access in WAF cloud CNAME access mode

    When using the cloud CNAME access mode, requests go through WAF and are checked for protection before being sent to the load balancer. This means that even if the load balancer has transparent transmission of source IP addresses enabled, the client will receive the back-to-source IP address of WAF. Consequently, the Nginx Ingress Controller is unable to obtain the real client IP address by default. In this case, you can edit the NGINX Ingress Controller add-on and add the following configuration to the add-on parameters:

    {
         "enable-real-ip": "true",
         "forwarded-for-header": "true",
         "proxy-real-ip-cidr": <Back-to-source IP address you obtained from WAF> 
    }
  • Load balancer access in the cloud WAF mode

    This mode is transparent access (non-inline deployment) and supports only dedicated load balancers. In this mode, Nginx Ingress Controllers can obtain the real client IP address by default.

LoadBalancer

For a LoadBalancer Service, different types of clusters obtain source IP addresses in different scenarios. In some scenarios, source IP addresses cannot be obtained currently. For details, see Scenarios in Which Source IP Address Can Be Obtained.
  • CCE Clusters (using VPC or Tunnel network): Source IP addresses can be obtained when either a shared or dedicated load balancer is used.
  • CCE Turbo Clusters (using the Cloud Native Network 2.0): Source IP addresses can be obtained for dedicated load balancers, and for shared load balancers with hostNetwork enabled.

VPC and Container Tunnel Network Models

To obtain source IP addresses, perform the following steps:

  1. When creating a LoadBalancer Service on the CCE console, set Service Affinity to Node-level instead of Cluster-level.

  2. Go to the ELB console and enable the function of obtaining the client IP address of the listener corresponding to the load balancer. Transparent transmission of source IP addresses is enabled for dedicated load balancers by default. You do not need to manually enable this function.

    1. Log in to the ELB console.
    2. Click in the upper left corner of the management console and select a region and a project.
    3. Click Service List. Under Networking, click Elastic Load Balance.
    4. On the Load Balancers page, click the name of the load balancer.
    5. Click the Listeners tab, locate the row containing the target listener, and click Edit. If modification protection exists, disable the protection on the basic information page of the listener and try again.
    6. Enable Transfer Client IP Address.
      Figure 3 Enabling the function

Cloud Native Network 2.0 Model (CCE Turbo Clusters)

In the Cloud Native Network 2.0 model, when a shared load balancer is used for load balancing, the service affinity cannot be set to Node-level. As a result, source IP addresses cannot be obtained. To obtain a source IP address, you must use a dedicated load balancer. External access to the container does not need to pass through the forwarding plane.

By default, transparent transmission of source IP addresses is enabled for dedicated load balancers. You do not need to manually enable Transfer Client IP Address on the ELB console. Instead, you only need to select a dedicated load balancer when creating a LoadBalancer Service on the CCE console.

NodePort

Set the service affinity of a NodePort Service to Node-level instead of Cluster-level. That is, set spec.externalTrafficPolicy of the Service to Local.

When a node (using Cloud Native Network 2.0) accesses a NodePort Service, source IP addresses can be obtained only when hostNetwork is enabled for workloads.

Figure 4 Selecting a node-level affinity