Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "how to obtain the real source IP of the client in the container service", so the editor summarizes the following contents for you. The content is detailed, the steps are clear, and it has a certain reference value. I hope you can get something after reading this article. Let's take a look at the article "how to obtain the real source IP of the client in the container service by kubernetes".

Why do I need to get the real source IP of the client?

When you need to be aware of the service request source to meet some business requirements, you need the back-end service to accurately obtain the real source IP of the request client, such as the following scenarios:

There is a need to audit the source of the service request, such as remote login alarm.

For security attacks or security events traceability requirements, such as APT attacks, DDoS attacks and so on.

Business scenario data analysis requirements, such as business request region statistics.

Other requirements that require access to client addresses.

How to obtain the real source IP of the client in the TKE usage scenario?

The default external load balancer in TKE is Tencent Cloud load balancer. As the first access entry for service traffic, Tencent Cloud load balancer forwards the request traffic load to the Kubernets Service of the Kubernetes worker node (default). This load balancing process retains the client's real source IP (transparent forwarding), but in the Kubernetes Service forwarding scenario, whether using iptbales or ipvs load balancer forwarding mode Packets are SNAT when forwarding, that is, the real source IP of the client is not retained. In order to accurately obtain the real source IP of the client, there are four main methods to obtain the real source IP of the client in the TKE usage scenario, which will be described one by one below.

1. Retain the client source IP through the configuration option of Service resources

To enable the reserved client IP feature, configure the field Service.spec.externalTrafficPolicy in the Service resource, which indicates whether the service wants to route external traffic to nodes local or cluster-wide endpoints. There are two option values: Cluster (default) and Local mode, as shown in the following figure:

Cluster indicates that the client source IP is hidden. Pods; Local with LoadBalancer and NodePort service traffic that may be forwarded to other nodes means to retain the client source IP and prevent LoadBalancer and NodePort service traffic from being forwarded to the Pods of other nodes. For more information, please see kubernets setting external load balancer instructions. Examples of related YAML configurations are as follows:

ApiVersion: v1kind: Servicemetadata: name: example-Servicespec: selector: app: example-Service ports:-port: 8765 targetPort: 9376 externalTrafficPolicy: Local type: LoadBalancer

Pros: you only need to modify the Kubernets Service resource configuration.

Disadvantages: there is a potential risk of unbalanced load of Pods (Endpoints) traffic.

Second, it can be obtained through TKE native CLB pass-through Pod forwarding mode.

Using the forwarding feature of CLB pass-through Pod natively supported by TKE (CLB pass-through forwarding and bypassing Kubernetes Service traffic forwarding), the source IP of the request received by the backend Pods is the real source IP of the client. This method is applicable in both layer-4 and layer-7 forwarding scenarios. The forwarding principle is as follows:

For more information and configuration, please see Tencent Cloud CLB Direct connection Pod usage scenarios under the TKE scenario.

Advantages: the features natively supported by TKE can only be configured according to the documentation in the console.

Disadvantages: VPC-CNI mode network needs to be enabled in the cluster. For more information, please see VPC-CNI mode instructions.

Third, obtain through HTTP Header

In a layer-7 (HTTP/HTTPS) service forwarding scenario, you can obtain the real source IP of the client by obtaining the values of X-Forwarded-For and X-Real-IP fields in Http Header. There are two scenarios to use in TKE. The principle is as follows:

In scenario 1, Tencent Cloud load balancer (CLB layer 7) puts the client real source IP into the X-Forwarded-For and X-Real-IP fields of HTTP Header by default. When service traffic is forwarded through layer 4 of Service, the above fields are retained. The backend obtains the client real source IP through WEB server proxy configuration or application code. For more information, please refer to the documentation on how to obtain the real IP of the client by load balancer-Best practices-document Center-Tencent Cloud

In scenario 2, Nginx Ingress service deployment requires that the Nginx Ingress can directly perceive the real source IP of the client. It can be configured by retaining the source IP of the client (see kubernets setting external load balancer instructions for details) or through CLB through Pod (for more information, please see the introduction to Tencent Cloud CLB Direct Pod usage scenarios under TKE scenario) When Nginx Ingress forwards the request, it records the client source IP through the X-Forwarded-For and X-Real-IP fields, and the backend can obtain the real source IP of the client through this field.

The following details describe the configuration and usage of the two scenarios in TKE:

Scenario 1: use TKE Ingress to get the real source IP

Create a Service resource with host port access for the workload in the TKE console, as shown below:

Then create a new Ingress access entry for Service in the console, as shown below:

After the configuration takes effect, the real source IP of the client can be obtained by obtaining the value of the X-Forwarded-For or X-Real-IP field in the HTTP Header at the backend. An example of the test result of grabbing package at the backend is as follows:

Scenario 2: use Nginx Ingress to get the real source IP

Nginx Ingress can be installed through the TKE App Store, custom YAML configuration or using the official (helm installation) method. For more information on how to deploy Nginx Ingress on TKE, please refer to deployment scenario 1 or scenario 3. If you choose option 1, you need to change the externalTrafficPolicy field value of Nginx Ingress Controller Service to Local. After the installation is complete, a CLB (four-tier) access entry is automatically created for the Nginx Ingress Controller service in the TKE console, as shown in the following figure:

Create an Ingress resource for the backend service to be forwarded and configure the forwarding rules, which can be created using the following YAML:

ApiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: nginx # ingressClass configure service forwarding rules for "nginx" name: example namespace: defaultspec: rules: # http: paths:-backend: serviceName: nginx servicePort: 80 path: /

After the configuration takes effect, obtain the X-Forwarded-For or X-Real-IP field value in Http Header at the backend to get the real source IP of the client. An example of the test result of grabbing the package at the backend is as follows:

The two scenarios described above can meet the requirements of obtaining the real source IP of the client, and have the following advantages and disadvantages:

Advantages: in layer-7 (HTTP/HTTPS) traffic forwarding scenarios, it is recommended that you can obtain the real IP of the client by directly obtaining the fields in the Http Header through the configuration of the WEB service proxy or the back-end application code, which is very simple and efficient.

Disadvantages: it is only suitable for layer-7 (HTTP/HTTPS) traffic forwarding scenarios, but not for layer-4 forwarding scenarios. If it is a layer-4 forwarding scenario, please use other methods described later.

4. Obtain the real source IP by loading the TOA kernel module

The principle and loading method of TOA kernel module refer to Global Application acceleration to get access to users' real IP-Operation Guide-document Center-Tencent Cloud documentation.

Advantages: for TCP transmission, there is almost no performance loss at the kernel level and only the first packet of the TCP connection is modified.

Disadvantages:

The TOA kernel module needs to be loaded on the cluster work node, and the source IP and port information need to be obtained through function calls on the server side, so it is troublesome to configure and use it.

For UDP transmission, option data (source IP and source port) will be added to each packet transformation, resulting in loss of network transmission channel performance.

The above is the content of this article on "how to obtain the real source IP of the client in container service by kubernetes". I believe everyone has some understanding. I hope the content shared by the editor will be helpful to you. If you want to learn more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.