Istio REGISTRY_ONLY模式下内外Pod访问问题及拦截咨询

为啥不需要ServiceEntry就能访问outside Pod？ #

你提到的outside Pod大概率有对应的K8S Service——Istio会自动把集群内所有K8S Service同步到自己的服务注册表，而REGISTRY_ONLY模式只是禁止访问注册表外的服务。所以当inside Pod通过Service名访问outside时，sidecar会判定这个服务在注册表内，直接放行，根本不需要额外创建ServiceEntry。

ServiceEntry的作用是补全注册表：比如添加集群外的服务、或者集群内没有对应K8S Service的Pod，这种场景才需要用它。如果是已经有K8S Service的Pod，完全不需要这一步。

另外还有一种可能：你是直接用outside Pod的IP访问的。如果sidecar没拦截目标端口（比如你用的端口不在Istio默认拦截范围内，或者自定义Sidecar配置排除了这个端口），流量会绕过sidecar直接发出去，自然不受REGISTRY_ONLY的限制。

先确认REGISTRY_ONLY真的生效了吗？ #

• 查全局Mesh配置：执行 istioctl pc mesh <inside-pod-name>.<namespace> -o json | jq '.trafficPolicy.outboundPolicy.mode'，看返回值是不是REGISTRY_ONLY。如果全局没开这个模式，只给单个Pod/Sidecar配置是没用的——REGISTRY_ONLY的全局开关在MeshConfig里，Sidecar资源主要是用来筛选出站服务范围，不是单独开这个模式的。
• 查sidecar监听端口：执行 istioctl pc listeners <inside-pod-name>.<namespace>，确认你curl用的端口（比如80）在sidecar的监听列表里。要是不在，说明流量根本没走sidecar，REGISTRY_ONLY当然管不着。

怎么拦截inside到outside的流量？ #

• 先把REGISTRY_ONLY全局开起来：修改IstioOperator配置，把spec.meshConfig.outboundTrafficPolicy.mode设为REGISTRY_ONLY，然后执行istioctl upgrade生效。
• 删掉outside对应的K8S Service：如果这个服务本来就不该被访问，直接删了它——Istio注册表没了这个服务，sidecar就会拦截所有指向它的流量。
• 用Sidecar资源精准限制出站范围：给inside Pod所在的命名空间或者单个Pod加个Sidecar配置，明确只允许访问指定服务，把outside的Service排除在外。示例配置：

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: restrict-outbound
  namespace: <你的inside命名空间>
spec:
  egress:
  - hosts:
    - "./*" # 只允许访问当前命名空间内的服务
    - "istio-system/*" # 保留Istio系统服务的访问权限，按需调整
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

• 拦截直接Pod IP访问：确保sidecar拦截所有出站端口（默认是开启的），如果之前有自定义排除端口的配置，把它删掉。同时可以配合K8S NetworkPolicy，阻止Pod之间直接绕开sidecar的通信。

内容的提问来源于stack exchange，提问作者Wanderer