kubernetes - 有没有办法阻止特使添加特定标题？

Question

根据此处的文档 https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-proto
Envoy 代理添加 Header X-Forwarded-Proto对于请求，由于某种原因 header 值错误；将其设置为 http虽然传入的请求方案是 https这会导致我的应用程序代码出现一些问题，因为它取决于此 header 的正确值。
这是特使中的错误吗？我可以阻止特使这样做吗？

Answer 1

正如我在评论中提到的，有相关的 github issue关于那个。

Is there a way to prevent envoy from adding specific headers?

有 istio dev @howardjohn comment关于那个

We currently have two options:

• EnvoyFilter
• Alpha api

There will not be a third; instead we will promote the alpha API.

所以第一个选项是特使过滤器。

在上面的 github 问题中有 2 个答案。
Answer由@jh-sz 提供

In general, use_remote_address should be set to true when Envoy is deployed as an edge node (aka a front proxy), whereas it may need to be set to false when Envoy is used as an internal service node in a mesh deployment.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: xff-trust-hops
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager"
          use_remote_address: true
          xff_num_trusted_hops: 1

和

Answer由@vadimi 提供

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: my-app-filter
spec:
  workloadLabels:
    app: my-app
  filters:
  - listenerMatch:
      portNumber: 5120
      listenerType: SIDECAR_INBOUND
    filterName: envoy.lua
    filterType: HTTP
    filterConfig:
      inlineCode: |
        function envoy_on_request(request_handle)
          request_handle:headers():replace("x-forwarded-proto", "https")
        end
        function envoy_on_response(response_handle)
        end

第二个选项是 Alpha api，这个功能正在积极开发中，被认为是 pre-alpha。

Istio provides the ability to manage settings like X-Forwarded-For (XFF) and X-Forwarded-Client-Cert (XFCC), which are dependent on how the gateway workloads are deployed. This is currently an in-development feature. For more information on X-Forwarded-For, see the IETF’s RFC.

You might choose to deploy Istio ingress gateways in various network topologies (e.g. behind Cloud Load Balancers, a self-managed Load Balancer or directly expose the Istio ingress gateway to the Internet). As such, these topologies require different ingress gateway configurations for transporting correct client attributes like IP addresses and certificates to the workloads running in the cluster.

Configuration of XFF and XFCC headers is managed via MeshConfig during Istio installation or by adding a pod annotation. Note that the Meshconfig configuration is a global setting for all gateway workloads, while pod annotations override the global setting on a per-workload basis.