Istio Sidecar未限制Service A访问Service E，是否需用出口网关？

你的Sidecar配置本应生效，但当前写法存在格式错误，导致规则未被正确应用，所以Service A仍能访问Service E。同时，你的需求不需要使用Egress Gateway，修正Sidecar配置即可实现访问控制。

问题根源：Egress Hosts的格式错误 #

你在配置中使用了./service-b.default.svc.cluster.local的写法，这是错误的。Istio中Sidecar egress hosts的合法格式有三种：

1. 相对格式：./<service-name>，表示当前命名空间下的指定服务
2. 命名空间+服务名：<namespace>/<service-name>，指定命名空间下的服务
3. 完整FQDN：<service-name>.<namespace>.svc.cluster.local，服务的完整域名

你将相对格式的./与完整FQDN混合使用，导致Istio无法正确识别要允许的服务，因此默认的出站规则（允许所有集群内流量）依然生效，没有限制未在列表中的Service E。

修正后的Sidecar配置 #

将hosts改为合法格式即可，以下两种写法都可行：

写法1：使用命名空间+服务名 #

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: service-a-sidecar
  namespace: default
spec:
  workloadSelector:
    labels:
      app: service-a
  egress:
  - hosts:
    - "default/service-b"
    - "default/service-c"
    - "default/service-d"
    - "istio-system/*"

写法2：使用完整FQDN #

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: service-a-sidecar
  namespace: default
spec:
  workloadSelector:
    labels:
      app: service-a
  egress:
  - hosts:
    - "service-b.default.svc.cluster.local"
    - "service-c.default.svc.cluster.local"
    - "service-d.default.svc.cluster.local"
    - "istio-system/*"

验证配置是否生效 #

应用修正后的配置并重启Service A的Pod后，可以通过以下步骤验证：

• 执行istioctl proxy-config outbound <service-a-pod-name> -n default，检查输出中是否只包含你允许的服务条目
• 再次测试Service A访问Service E，此时应该被Istio代理拒绝

是否需要Egress Gateway？ #

不需要。Egress Gateway主要用于集群外流量的集中管控（比如统一出口、加密、监控），而你的需求是集群内服务间的访问控制，通过Sidecar的egress配置完全可以实现，无需额外部署Egress Gateway。

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