我已经使用this在Istio 1.10.2中应用了kiali。现在,我正在尝试通过过滤源ip地址来保护它。我尝试使用授权策略,但它不起作用。它继续允许每个人在it should deny any request that is not in the ALLOW policy
AuthorizationPolicy:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: kiali-ingress-policy-allow
namespace: istio-system
spec:
selector:
matchLabels:
app: kiali
action: ALLOW
rules:
- from:
- source:
remoteIpBlocks: ["10.43.212.247/32","10.43.212.242/32"]VirtualService:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: kiali
namespace: istio-system
spec:
hosts:
- "kiali.myinternaldomain.local"
gateways:
- istio-system/my-internal-gateway
http:
- match:
- uri:
prefix: /
route:
- destination:
host: kiali
port:
number: 20001已使用默认配置文件和这些额外参数安装ISTIO:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
accessLogFile: /dev/stdout
components:
ingressGateways:
- name: istio-ingressgateway
enabled: true
k8s:
overlays:
- apiVersion: apps/v1
kind: Deployment
name: istio-ingressgateway
patches:
- path: kind
value: DaemonSet
- path: spec.strategy
- path: spec.updateStrategy
value:
rollingUpdate:
maxUnavailable: 50%
type: RollingUpdate
egressGateways:
- name: istio-egressgateway
enabled: true
k8s:
hpaSpec:
minReplicas: 2
pilot:
k8s:
hpaSpec:
minReplicas: 2
values:
gateways:
istio-ingressgateway:
autoscaleEnabled: false
env:
ISTIO_META_HTTP10: '1'
pilot:
env:
PILOT_HTTP10: '1'发布于 2021-11-25 11:13:02
我设法在GCP VMs上的Istio1.10.2中设置了工作ALLOW策略,集群是使用带有Calico CNI插件的kubeadm设置的。我使用了这个文档-- Ingress Gateway。
注意:我将istio-ingressgateway服务类型更改为NodePort服务,而不是LoadBalancer,但在这种情况下这并不重要。
我的网络设计如下:
中
我部署了以下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>所以它工作正常。
I 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...and我在服务中将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的允许列表,仅允许主机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的虚拟机上,curl与以前一样工作,但在地址为10.xxx.0.3的虚拟机上,我们可以注意到:
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 - -重要的是:
istio-ingressgateway-{..}的日志中注意到另一个虚拟机的源IP地址,以便策略可以允许/阻止app: ingress-istio-ingressgateway (而不是pod根据您的设置,它应该是ipBlocks如果您使用X-Forwarded- ipBlocks remoteIpBlocks**:**或代理协议来确定原始客户端IP地址,则应在AuthorizationPolicy中使用。如果你正在使用externalTrafficPolicy: Local,那么你应该在你的AuthorizationPolicy中使用ipBlocks。
发布于 2021-11-25 13:59:24
正如@mikolaj-s所指出的,解决方案是将选择器更改为istio-ingressgateway。我尝试使用选择器kiali,因为这是我在其他名称空间中用于其他工作负载的方式。即使app标签配置完美:
> kubectl get services -l app=kiali -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-system kiali ClusterIP 10.97.200.171 <none> 20001/TCP,9090/TCP 13d
> kubectl get pods -l app=kiali -A
NAMESPACE NAME READY STATUS RESTARTS AGE
istio-system kiali-6fbbc6d8c9-rctjh 1/1 Running 0 47h我还更改了逻辑,以使用操作"DENY“、源"notIpBlocks”并指定主机名。
最终有效的AuthorizationPolicy是:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: kiali-ingress-policy-allow
namespace: istio-system
spec:
action: DENY
rules:
- from:
- source:
notIpBlocks: ["10.43.212.247/32","10.43.212.242/32"]
to:
- operation:
hosts:
- kiali.myinternaldomain.local
selector:
matchLabels:
app: istio-ingressgatewayhttps://stackoverflow.com/questions/69884920
复制相似问题