我设法在 GCP VMs 上的 Istio 1.10.2 中设置工作 ALLOW 策略，集群是使用带有 Calico CNI 插件的 kubeadm 设置的。我使用了这个文档 - Ingress Gateway。
注意：我将istio-ingressgateway 服务类型更改为NodePort 服务而不是LoadBalancer，但这在这种情况下并不重要。
我的网络设计如下：
- 第一个虚拟机 - Kubernetes 节点 - 10.xxx.0.2 地址
- 第二个虚拟机 - 10.xxx.0.3 地址
- 第三个虚拟机 - 10.xxx.0.4 地址 - 此地址将在 ALLOW 策略中
我部署了以下 NGINX 服务和部署...
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
ports:
- name: http
port: 80
targetPort: 80
selector:
app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deply
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
version: v1
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
...以及以下网关和虚拟服务定义：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nginx-vs
spec:
hosts:
- "my-test.com"
gateways:
- gateway
http:
- route:
- destination:
host: nginx-svc
port:
number: 80
查看虚拟服务定义中的nginx-svc服务名称（你应该使用你要配置的那个）。
我可以从网络中的每个虚拟机运行以下命令：
user@vm-istio:~$ curl 10.xxx.0.2:31756 -H "Host: my-test.com"
<!DOCTYPE html>
...
<title>Welcome to nginx!</title>
所以它工作正常。
我enabled RBAC debugging for the ingress gateway pod...
kubectl get pods -n istio-system -o name -l istio=ingressgateway | sed 's|pod/||' | while read -r pod; do istioctl proxy-config log "$pod" -n istio-system --level rbac:debug; done
...我将externalTrafficPolicy 设置为Local 在服务中istio-ingressgateway 设置为preserve an IP address from the original client：
kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"externalTrafficPolicy":"Local"}}
在 istio 入口网关控制器的日志中，我可以看到请求即将到来并且它们正在继续：
kubectl logs istio-ingressgateway-5d57955454-9mz4b -n istio-system -f
...
[2021-11-24T13:39:47.220Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 1 0 "10.xxx.0.3" "curl/7.64.0" "69953f69-8a46-9e2a-a5a7-36861bae4a77" "my-test.com" "192.168.98.74:80" outbound|80||nginx-svc.default.svc.cluster.local 192.168.98.72:60168 192.168.98.72:8080 10.xxx.0.3:55160 - -
[2021-11-24T13:39:48.980Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 1 0 "10.xxx.0.4" "curl/7.64.0" "89284e11-42f9-9e84-b256-d3ea37311e92" "my-test.com" "192.168.98.74:80" outbound|80||nginx-svc.default.svc.cluster.local 192.168.98.72:60192 192.168.98.72:8080 10.xxx.0.4:35800 - -
现在，我将应用基于 IP 的允许列表以仅允许第二个 VM 地址托管 my-test.com：
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: ingress-policy
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
action: ALLOW
rules:
- from:
- source:
ipBlocks: ["10.xxx.0.4"]
to:
- operation:
hosts:
- "my-test.com"
在地址为 10.xxx.0.4 的 VM 上 curl 像以前一样工作，但在地址为 10.xxx.0.3 的 VM 上，我们可以注意到以下内容：
user@vm-istio:~$ curl 10.xxx.0.2:31756 -H "Host: my-test.com"
RBAC: access denied
所以它按预期工作。
在 istio 入口网关控制器的日志中，我们可以注意到请求被拒绝（查找与 RBAC 相关的日志）：
kubectl logs istio-ingressgateway-5d57955454-9mz4b -n istio-system -f
2021-11-24T14:05:11.382613Z debug envoy rbac checking request: requestedServerName: , sourceIP: 10.xxx.0.3:55194, directRemoteIP: 10.xxx.0.3:55194, remoteIP: 10.xxx.0.3:55194,localAddress: 192.168.98.72:8080, ssl: none, headers: ':authority', 'my-test.com'
':path', '/'
':method', 'GET'
':scheme', 'http'
'user-agent', 'curl/7.64.0'
'accept', '*/*'
'x-forwarded-for', '10.xxx.0.3'
'x-forwarded-proto', 'http'
'x-envoy-internal', 'true'
'x-request-id', '63c0f55c-5545-92a0-80fc-aa2a5a63bf04'
'x-envoy-decorator-operation', 'nginx-svc.default.svc.cluster.local:80/*'
'x-envoy-peer-metadata', '...'
'x-envoy-peer-metadata-id', 'router~192.168.98.72~istio-ingressgateway-5d57955454-9mz4b.istio-system~istio-system.svc.cluster.local'
, dynamicMetadata:
2021-11-24T14:05:11.382662Z debug envoy rbac enforced denied, matched policy none
[2021-11-24T14:05:11.382Z] "GET / HTTP/1.1" 403 - rbac_access_denied_matched_policy[none] - "-" 0 19 0 - "10.xxx.0.3" "curl/7.64.0" "63c0f55c-5545-92a0-80fc-aa2a5a63bf04" "my-test.com" "-" outbound|80||nginx-svc.default.svc.cluster.local - 192.168.98.72:8080 10.xxx.0.3:55194 - -
尤其是这部分：
[2021-11-24T14:05:11.382Z] "GET / HTTP/1.1" 403 - rbac_access_denied_matched_policy[none]
这清楚地表明我们的政策正在发挥作用。
允许我们请求的日志示例：
2021-11-25T10:58:34.717495Z debug envoy rbac enforced allowed, matched policy ns[istio-system]-policy[ingress-policy]-rule[0]
[2021-11-25T10:58:34.717Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 25 23 "10.xxx.0.4" "curl/7.64.0" "889e3326-093c-94b1-b856-777c06cbe2b7" "my-test.com" "192.168.98.75:80" outbound|80||nginx-svc.default.svc.cluster.local 192.168.98.72:46190 192.168.98.72:8080 10.xxx.0.4:37148 - -
什么是重要的：
- 确保在 pod
istio-ingressgateway-{..} 的日志中可以注意到其他 VM 的源 IP 地址，以便策略可以允许/阻止
- 我的建议是在服务网格边缘设置 AuthorizationPolicy 用于外部流量 - 这是 istio 入口网关，这就是为什么我的 AuthorizationPolicy 使用“选择器”匹配标签
app: ingress-istio-ingressgateway（不是 kiali )
-
use a proper type of IPs -
ipBlocks vs remoteIpBlocks。根据您的设置，它应该是ipBlocks：
何时使用ipBlocks vs. remoteIpBlocks：如果您使用 X-Forwarded-For HTTP 标头或代理协议来确定原始客户端 IP 地址，那么您应该使用remoteIpBlocks 在您的 AuthorizationPolicy 中。如果您使用的是externalTrafficPolicy: Local，那么您应该在您的AuthorizationPolicy 中使用ipBlocks。