Skip to content

GitLab

Open
Created by ran.lu@ran.luMaintainer

问题: 发向 pch-bff-pipeline 的请求没有经过 ext auth rpc 的检查

已知: 在 pch-bff-pipeline 做了一个 rpc 服务，用作 istio ext auth 的提供方

问题现象: 通过观察日志, 发现:

  • 发向 pch-bff-pipeline 的请求没有经过 ext auth rpc 的检查
  • 发向 admagic-backend 等后端的请求有经过 ext auth rpc 的检查

istio 版本:

istioctl version
client version: 1.9.4
pilot version: 1.9.4
pilot version: 1.9.4
pilot version: 1.9.4
pilot version: 1.9-dev-13fb8ac89420d8cc5b3f895adc614233e805a61c
data plane version: 1.9.4 (60 proxies), 1.9-dev (4 proxies)

envoy版本

envoy --version

envoy  version: daadd2f2b671ea13684536299e97b819debad136/1.17.1/Clean/RELEASE/BoringSSL

做了哪些尝试:

  1. 已经检查了 virtual service 等配置, 并没有看出问题。
  2. 起了一个 nginx deployment, 观察是否会经过 ext auth rpc 检查。发现是有的。
  3. 在 istio-proxy 中，可以访问 127.0.0.1:15000/config_dump 查看 envoy 配置。截取了一段有关配置，大概是像下面那样，目前还没看出啥来。
    {
           "name": "envoy.filters.network.ext_authz",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.ext_authz.v3.ExtAuthz",
            "stat_prefix": "tcp.",
            "grpc_service": {
             "envoy_grpc": {
              "cluster_name": "outbound|9000||pch-bff-pipeline.apulis.svc.cluster.local",
              "authority": "outbound_.9000_._.pch-bff-pipeline.apulis.svc.cluster.local"
             },
             "timeout": "600s"
            },
            "transport_api_version": "V3",
            "filter_enabled_metadata": {
             "filter": "envoy.filters.network.rbac",
             "path": [
              {
               "key": "shadow_effective_policy_id"
              }
             ],
             "value": {
              "string_match": {
               "prefix": "istio-ext-authz"
              }
             }
            }
           }
  1. 验证一下 iam 的 ext auth ，看它是不是也会检查发到它自身的请求.
curl -k https://192.168.3.172/iam/api/v1/xx -v

==>

{"level":"error","error":"empty token values","time":"2023-01-05 07:29:53","traceId":"159414","caller":"/go/src/github.com/apulisai/bmod/iam/internal/controllers/authorize.go:359","time":"2023-01-05 07:29:53","message":"get token from istio error"}

从这个日志来看，结合 iam 代码， ext auth rpc 是有生效的。这个环境，是好的，是参考环境。

  1. 现在打算分析 istio 的路由规则。

  2. 想到 istio 规则理论上是体现不到这个 ext auth 的，因为 ext auth 发生于一个请求的“中间”，还是得去看 envoy 。下一步打算再去分析一下 envoy 的配置。

  3. 在 istio 论坛上提了个问题: https://discuss.istio.io/t/ext-authz-does-not-check-traffic-routed-to-itself/14698 (后来发现问题所在后，已经自己回复了自己…）

8. 后来还是去看 envoy 配置 config_dump

kubectl exec -it -n apulis admagic-bff-56c88469c5-smsh9 -c istio-proxy -- curl 127.0.0.1:15000/config_dump > tmp_config_dump

去导出了 3.172 的 iam 的 envoy 配置，和 1.37 的 pch-bff-pipeline 的 envoy 配置, 进行对比。

我在两个文件中，对比搜索了多个关键字。

后来是destination_port": 80,关键字，产生了启发。

iam backend config 是这样的iam-backend_config_dump.json，截取有关部分如下:

{
              "name": "envoy.filters.http.rbac",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC",
               "shadow_rules": {
                "action": "DENY",
                "policies": {
                 "istio-ext-authz-ns[istio-system]-policy[aaa-grpc]-rule[0]": {
                  "permissions": [
                   {
                    "and_rules": {
                     "rules": [
                      {
                       "or_rules": {
                        "rules": [
                         {
                          "url_path": {
                           "path": {
                            "prefix": "/api/v1"
                           }
                          }
                         }
                        ]
                       }
                      }
                     ]
                    }
                   }
                  ],
                  "principals": [
                   {
                    "and_ids": {
                     "ids": [
                      {
                       "or_ids": {
                        "ids": [
                         {
                          "header": {
                           "name": "From",
                           "exact_match": "fronted"
                          }
                         }
                        ]
                       }
                      }
                     ]
                    }
                   }
                  ]
                 }
                }
               }
              }
             },

而 pch-bff-pipeline 里面是这样的pch-bff-pipeline_config_dump_20230106，截取有关部分如下：


 {
         "filter_chain_match": {
          "destination_port": 80,
          "transport_protocol": "tls"
         },

……


{
           "name": "envoy.filters.network.rbac",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.rbac.v3.RBAC",
            "shadow_rules": {
             "action": "DENY",
             "policies": {
              "istio-ext-authz-ns[istio-system]-policy[aaa-grpc]-rule[0]": {
               "permissions": [
                {
                 "and_rules": {
                  "rules": [
                   {
                    "any": true
                   }
                  ]
                 }
                }
               ],
               "principals": [
                {
                 "and_ids": {
                  "ids": [
                   {
                    "any": true
                   }
                  ]
                 }
                }
               ]
              }
             }
            },
            "stat_prefix": "tcp."
           }
          },

pch-bff-pipeline 这里的 any true 比较可疑。这是完全放行了？

后面联想到，现在集群里有 pch-bff-pipeline 的 peerAuthentication ，还有个 pch-bff-pipeline 的 NodePort .

于是把 pch-bff-pipeline 的 peerAuthentication 和 NodePort 都删掉了，就有预期的现象了。后来把 peerAuthentication 恢复回来，仍然没问题。

把 NodePort 删除后，使用kubectl exec -it -n apulis pch-bff-pipeline-6664d454fd-msmd6 -c istio-proxy -- curl 127.0.0.1:15000/config_dump > luran/pch-bff-pipeline_config_dump_20230106_2再看配置，是这样的pch-bff-pipeline_config_dump_20230106_2，确实没有destination_port": 80,的 any true 了。

总之，认为直接原因是 NodePort 有干扰。

具体是什么原因，还没有想明白。

Edited by ran.lu