Istio的流量管理(实操三)
涵盖官方文档Traffic Management章节中的egress部分。
涵盖官方文档Traffic Management章节中的egress部分。
由于启用了istio的pod的出站流量默认都会被重定向到代理上,因此对集群外部URL的访问取决于代理的配置。默认情况下,Envoy代理会透传对未知服务的访问,虽然这种方式为新手提供了便利,但最好配置更严格的访问控制。
本节展示使用如下三种方式访问外部服务:
部署sleep app,用于发送请求。
$ kubectl apply -f samples/sleep/sleep.yaml
设置SOURCE_POD
为请求源pod名
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
istio有一个安装选项,meshConfig.outboundTrafficPolicy.mode
,用于配置sidecar处理外部服务(即没有定义到istio内部服务注册中心的服务)。如果该选项设置为ALLOW_ANY
,则istio代理会放行到未知服务的请求;如果选项设置为REGISTRY_ONLY
,则istio代理会阻塞没有在网格中定义HTTP服务或服务表项的主机。默认值为ALLOW_ANY
,允许快速对istio进行评估。
首先将meshConfig.outboundTrafficPolicy.mode
选项设置为ALLOW_ANY
。默认应该就是ALLOW_ANY
,使用如下方式获取当前的模式:
$kubectl get configmap istio -n istio-system -o yaml |grep -o "mode: ALLOW_ANY" |uniq
mode: ALLOW_ANY
如果没有配置模式,可以手动添加:
outboundTrafficPolicy:
mode: ALLOW_ANY
从网格内向外部服务发送两个请求,可以看到请求成功,返回200
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.baidu.com | grep "HTTP/"; kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://edition.cnn.com | grep "HTTP/"
HTTP/1.1 200 OK
HTTP/2 200
使用这种方式可以访问外部服务,但无法对该流量进行监控和控制,下面介绍如何监控和控制网格到外部服务的流量。
使用ServiceEntry配置可以从istio集群内部访问公共服务。本节展示如何配置访问外部HTTP服务,httpbin.org以及www.baidu.com,同时会监控和控制istio流量。
为了展示如何控制访问外部服务的方式,需要将meshConfig.outboundTrafficPolicy.mode
设置为REGISTRY_ONLY
执行如下命令将meshConfig.outboundTrafficPolicy.mode
选项设置为REGISTRY_ONLY
$ kubectl get configmap istio -n istio-system -o yaml | sed 's/mode: ALLOW_ANY/mode: REGISTRY_ONLY/g' | kubectl replace -n istio-system -f -
从SOURCE_POD访问外部HTTPS服务,此时请求会被阻塞(可能需要等一段时间来使配置生效)
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.baidu.com | grep "HTTP/"; kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://edition.cnn.com | grep "HTTP/"
command terminated with exit code 35
command terminated with exit code 35
创建一个ServiceEntry
注册外部服务,这样就可以直接访问外部HTTP服务,可以看到此处并没有用到virtual service和destination rule
下面serviceEntry使用
DNS
作为resolution是一种比较安全的方式,将resolution设置为NONE
将可能导致攻击。例如,恶意客户可能会再HOST首部中设置httpbin.org
,但实际上访问的不同的IP地址。istio sidecar代理会信任HOST首部,并错误地允许此次访问(即使会将流量传递到不同于主机的IP地址),该主机可能是一个恶意网站,或是一个被网格安全策略屏蔽的合法网站。使用
DNS
resolution时,sidecar代理会忽略原始目的地址,并将流量传递给hosts
字段的主机。在转发流量前会使用DNS请求hosts
字段的IP地址。serviceEntry包括如下三种resolution:
Name Description NONE
Assume that incoming connections have already been resolved (to a specific destination IP address). Such connections are typically routed via the proxy using mechanisms such as IP table REDIRECT/ eBPF. After performing any routing related transformations,the proxy will forward the connection to the IP address to which the connection was bound. STATIC
Use the static IP addresses specified in endpoints (see below) as the backing instances associated with the service. DNS
Attempt to resolve the IP address by querying the ambient DNS,during request processing. If no endpoints are specified,the proxy will resolve the DNS address specified in the hosts field,if wildcards are not used. If endpoints are specified,the DNS addresses specified in the endpoints will be resolved to determine the destination IP address. DNS resolution cannot be used with Unix domain socket endpoints.
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: httpbin-ext
spec:
hosts:
- httpbin.org #外部服务URI
ports:
- number: 80 #外部服务HTTP端口信息
name: http
protocol: HTTP
resolution: DNS
location: MESH_EXTERNAL # 表示一个外部服务,即httpbin.org是网格外部的服务
EOF
从SOURCE_POD请求外部HTTP服务
$ kubectl exec -it $SOURCE_POD -c sleep -- curl http://httpbin.org/headers
{
"headers": {
"Accept": "*/*","Content-Length": "0","Host": "httpbin.org","User-Agent": "curl/7.64.0",...
"X-Envoy-Decorator-Operation": "httpbin.org:80/*",}
}
注意HTTP添加了istio sidecar代理首部X-Envoy-Decorator-Operation
。
校验SOURCE_POD
sidecar代理的日志
$ kubectl logs $SOURCE_POD -c istio-proxy | tail
创建ServiceEntry允许访问外部HTTPS服务
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: baidu
spec:
hosts:
- www.baidu.com
ports:
- number: 443 # 外部服务HTTPS端口
name: https
protocol: HTTPS #指定外部服务为HTTPS协议
resolution: DNS
location: MESH_EXTERNAL
EOF
从SOURCE_POD
访问外部服务
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.baidu.com | grep "HTTP/"
HTTP/1.1 200 OK
与管理集群内部的流量类似,istio 的路由规则也可以管理使用ServiceEntry
配置的外部服务。本例将会为httpbin.org
服务设置一个超时规则.
从测试的pod向外部服务httpbin.org
的/delay地址发送一个请求,大概5s后返回200
$ kubectl exec -it $SOURCE_POD -c sleep -- time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5
200
real 0m 5.43s
user 0m 0.00s
sys 0m 0.00s
对外部服务httpbin.org
设置一个3s的超时时间
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: httpbin-ext
spec:
hosts:
- httpbin.org #此处的hosts与serviceEntry的hosts字段内容对应
http:
- timeout: 3s
route:
- destination:
host: httpbin.org
weight: 100
EOF
几秒后,重新访问该服务,可以看到访问超时
$ kubectl exec -it $SOURCE_POD -c sleep -- time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5
504
real 0m 3.02s
user 0m 0.00s
sys 0m 0.00s
$ kubectl delete serviceentry httpbin-ext google
$ kubectl delete virtualservice httpbin-ext --ignore-not-found=true
可以配置Envoy sidecar,使其不拦截特定IP段的请求。为了实现该功能,可以修改global.proxy.includeIPRanges
或global.proxy.excludeIPRanges
配置选项(类似白名单和黑名单),并使用kubectl apply
命令更新istio-sidecar-injector
配置。也可以修改annotations traffic.sidecar.istio.io/includeOutboundIPRanges
来达到相同的效果。在更新istio-sidecar-injector
配置后,相应的变动会影响到所有的应用pod。
与使用ALLOW_ANY流量策略配置sidecar放行所有到未知服务的流量不同,上述方式会绕过sidecar的处理,即在特定IP段上不启用istio功能。使用这种方式不能增量地为特定目的地添加service entry,但使用
ALLOW_ANY
方式是可以的,因此这种方式仅仅建议用于性能测试或其他特殊场景中。
一种不把到外部IP的流量重定向到sidecar代理的方式是将global.proxy.includeIPRanges
设置为集群内部服务使用的一个IP段或多个IP段。
找到平台使用的内部IP段后,就可以使用如下方式配置includeIPRanges
,这样目的地非10.0.0.1/24
的流量会绕过sidecar的处理。
$ istioctl manifest apply <the flags you used to install Istio> --set values.global.proxy.includeIPRanges="10.0.0.1/24"
本节介绍了三种访问外部服务的方式:
第一种方式的流量会经过istio sidecar代理,当使用这种方式时,无法监控访问外部服务的流量,无法使用istio的流量控制功能。第二种方法可以在调用集群内部或集群外部的服务时充分使用istio服务网格特性,本章的例子中,在访问外部服务时设置了超时时间。第三种方式会绕过istio sidecar代理,直接访问外部服务。然而这种方式需要指定集群的配置,与第一种方式类似,这种方式也无法监控到外部服务的流量,且无法使用istio的功能。
$ kubectl delete -f samples/sleep/sleep.yaml
检查当前的模式
$ kubectl get configmap istio -n istio-system -o yaml | grep -o "mode: ALLOW_ANY" | uniq
$ kubectl get configmap istio -n istio-system -o yaml | grep -o "mode: REGISTRY_ONLY" | uniq
将模式从ALLOW_ANY
切换到REGISTRY_ONLY
$ kubectl get configmap istio -n istio-system -o yaml | sed 's/mode: ALLOW_ANY/mode: REGISTRY_ONLY/g' | kubectl replace -n istio-system -f -
将模式从REGISTRY_ONLY
切换到ALLOW_ANY
$ kubectl get configmap istio -n istio-system -o yaml | sed 's/mode: REGISTRY_ONLY/mode: ALLOW_ANY/g' | kubectl replace -n istio-system -f -
本节展示如何通过配置istio来(对到外部服务的流量)初始化TLS。当原始流量为HTTP时,Istio会与外部服务建立HTTPS连接,即istio会加密到外部服务的请求。
创建sleep
应用
$ kubectl apply -f samples/sleep/sleep.yaml
获取sleep
的pod名
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
创建ServiceEntry
和VirtualService
访问 edition.cnn.com
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: edition-cnn-com
spec:
hosts:
- edition.cnn.com #外部服务URI
ports:
- number: 80 # HTTP访问
name: http-port
protocol: HTTP
- number: 443 # HTTPS访问
name: https-port
protocol: HTTPS #指定外部服务为HTTPS协议
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: edition-cnn-com
spec:
hosts:
- edition.cnn.com #外部服务URI
tls: #非终结的TLS&HTTPS流量
- match: #将edition.cnn.com:443的流量分发到edition.cnn.com:443
- port: 443
sniHosts:
- edition.cnn.com
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
EOF
访问外部服务,下面使用了-L
选项使请求端依照返回的重定向信息重新发起请求。第一个请求会发往http://edition.cnn.com/politics
,服务端会返回重定向信息,第二个请求会按照重定向信息发往https://edition.cnn.com/politics
。可以看到第一次是HTTP
访问,第二次是HTTPS
访问。
如果没有上述VirtualService,也可以通过下面命令进行访问。此处应该是为了与下面例子结合。
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
location: https://edition.cnn.com/politics
...
HTTP/2 200
...
上述过程会有两个弊端:上面的第一个HTTP访问显然是冗余的;如果在应用和edition.cnn.com
之间存在攻击者,这样该攻击者就可以通过嗅探链路获取请求端执行的操作,存在安全风险。
使用istio的TLS源可以解决如上问题。
重新定义 ServiceEntry
和VirtualService
,并增加DestinationRule
来发起TLS。此时VirtualService
会将HTTP请求流量从80端口重定向到DestinationRule
的443端口,然后由DestinationRule
来发起TLS。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry # serviceEntry跟前面配置一样
Metadata:
name: edition-cnn-com
spec:
hosts:
- edition.cnn.com #注册到注册中心的host。用于选择virtualService和DestinationRule
ports:
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: https-port-for-tls-origination
protocol: HTTPS
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: edition-cnn-com #请求的hosts字段
spec:
hosts:
- edition.cnn.com #请求中的hosts字段内容
http:
- match:
- port: 80 #后续将http流量通过destinationrule转换为https流量
route:
- destination:
host: edition.cnn.com #此时定义了DestinationRule,会经过DestinationRule处理
subset: tls-origination
port:
number: 443
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: edition-cnn-com
spec:
host: edition.cnn.com #istio注册表中的服务
subsets:
- name: tls-origination
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings: #配置与上游服务edition.cnn.com的连接。即在443端口上使用tls SIMPLE进行连接
- port:
number: 443
tls:
mode: SIMPLE # initiates HTTPS when accessing edition.cnn.com
EOF
向http://edition.cnn.com/politics
发送请求,可以看到此时会返回200,且不会经过重定向,相当于做了一个代理。
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 200 OK
...
当然直接使用https进行访问也是可以的,与上面使用http进行访问的结果相同kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
由于应用和sidecar代理之间是没有加密。因此渗透到应用所在的node节点的攻击者仍然能够看到该节点上未加密的本地通信内容。对于安全性较高的场景,建议应用直接使用HTTPS。
$ kubectl delete serviceentry edition-cnn-com
$ kubectl delete virtualservice edition-cnn-com
$ kubectl delete destinationrule edition-cnn-com
$ kubectl delete -f samples/sleep/sleep.yaml
本节描述如何通过一个指定的egress网关访问外部服务。istio使用ingress和egress网关在服务网格边界配置负载均衡。一个ingress网关允许定义网格的入站点,egress网关的用法类似,定义了网格内流量的出站点。
假设在一个安全要求比较高的组织中,所有离开服务网格的流量都要经过一个指定的节点(前面的egress访问都是在离开pod之后按照k8s方式访问,并没有指定必须经过某个节点),这些节点会运行在指定的机器上,与运行应用的集群的节点分开。这些特定的节点会在出站流量上应用策略,且对这些节点的监控将更加严格。
另外一个场景是集群中的应用所在的节点没有公网IP,因此网格内部的服务无法访问因特网。定义一个egress网关并为该网关所在的节点分配公网IP,这样流量就可以通过该节点访问公网服务。
创建sleep应用并获取Pod名
$ kubectl apply -f samples/sleep/sleep.yaml
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
校验是否已经部署istio egress网关
$ kubectl get pod -l istio=egressgateway -n istio-system
如果没有部署,执行如下步骤部署egress网关
$ istioctl manifest apply -f cni-annotations.yaml --set values.global.istioNamespace=istio-system --set values.gateways.istio-ingressgateway.enabled=true --set values.gateways.istio-egressgateway.enabled=true
注意:apply的时候使用自己定制化的文件,否则系统会使用默认的profile,导致配置丢失!
下面操作关于在
default
命名空间中为egress网关创建destination rule,因此要求sleep
应用也部署在default
命名空间中。如果应用不在default命名空间中,将无法在destination rule查找路径找到destination rule,客户端请求将会失败。
上面例子中,当网格内的客户端可以直接访问外部服务,此处将会创建一个egress网关,内部流量访问外部服务时会经过该网关。创建一个ServiceEntry
允许流量访问外部服务edition.cnn.com
:
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports: #可以通过HTTP和HTTPS服务外部服务
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
EOF
校验请求能够发往http://edition.cnn.com/politics,此处的操作与上一节相同。
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
HTTP/2 200
...
为edition.cnn.com
创建一个Gateway
,端口80,监听来自edition.cnn.com:80
的流量。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port: #监听来自edition.cnn.com:80的流量,
number: 80
name: http
protocol: HTTP
hosts:
- edition.cnn.com
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule #该DestinationRule没有定义任何规则,实际可以删除该DestinationRule,并删除下面VirtualService的"subset: cnn"一行
Metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn #下面VirtualService中会用到
EOF
定义VirtualService
,将流量从sidecar定向到egress网关,然后将流量从egress网关定向到外部服务。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways: #列出应用路由规则的网关
- istio-egressgateway
- mesh #istio保留字段,表示网格中的所有sidecar,当忽略gateways字段时,默认会使用mesh,此处表示所有sidecar到edition.cnn.com的请求
http: #采用http路由规则
- match: #各个match是OR关系
- gateways: #处理mesh网关,将来自mesh的edition.cnn.com:80请求发往istio-egressgateway.istio-system.svc.cluster.local:80
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn #对应DestinationRule中的subset名,由于使用了subset,因此必须使用DestinationRule。删除该行后就可以不使用上面的DestinationRule
port:
number: 80
weight: 100
- match:
- gateways:
- istio-egressgateway #处理istio-egressgateway网关,将来自gateway edition.cnn.com:80的请求发往edition.cnn.com:80
port: 80
route:
- destination:
host: edition.cnn.com #该host就对应serviceEntry注册的服务地址
port:
number: 80
weight: 100
EOF
发送HTTP请求http://edition.cnn.com/politics
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
HTTP/2 200
...
校验egress日志(需要启用Envoy日志)
$ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail
[2020-08-25T14:55:49.810Z] "GET /politics HTTP/2" 301 - "-" "-" 0 0 1445 1444 "10.80.3.231" "curl/7.64.0" "2151bde2-4382-4e2f-b088-e464943c2a9b" "edition.cnn.com" "151.101.1.67:80" outbound|80||edition.cnn.com 10.80.3.232:51516 10.80.3.232:8080 10.80.3.231:38072 - -
本例中仍然实在sleep pod中执行HTTP请求,通过301重定向重新发送HTTPS请求,而上面规则中并没有将HTTPs流程转发给网关,因此从上面网关上看不到到443端口的流量,但可以在sleep的istio-proxy sidecar的日志中可以看到完整的流量信息,如下:
[2020-08-25T14:55:33.114Z] "GET /politics HTTP/1.1" 301 - "-" "-" 0 0 310 310 "-" "curl/7.64.0" "d57ddf5f-985b-431a-8766-7481b75dc486" "edition.cnn.com" "151.101.1.67:80" outbound|80||edition.cnn.com 10.80.3.231:48390 151.101.65.67:80 10.80.3.231:44674 - default
[2020-08-25T14:55:33.439Z] "- - -" 0 - "-" "-" 906 1326852 5490 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 10.80.3.231:47044 151.101.65.67:443 10.80.3.231:42990 edition.cnn.com -
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-cnn
本节展示通过egress网关定向HTTPS
流量,。会使用到ServiceEntry
,一个egress Gateway
和一个VirtualService
。
创建到edition.cnn.com
的ServiceEntry
,定义外部服务https://edition.cnn.com
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 443
name: tls
protocol: TLS #protocol为TLS,用于非终结的流量
resolution: DNS
EOF
protocol字段可以为
HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TLS
其中之一,其中TLS 表示不会终止TLS连接,且连接会基于SNI首部进行路由。
校验可以通过ServiceEntry
访问https://edition.cnn.com/politics
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
HTTP/2 200
...
为edition.cnn.com
创建egress Gateway
,一个destination rule和一个virtual service。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: tls
protocol: TLS #该字段与serviceEntry的字段相同
hosts:
- edition.cnn.com
tls:
mode: PASSTHROUGH #透传模式,不在网关上终止TLS,由sidecar发起TLS
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- mesh
- istio-egressgateway
tls: #此处由http变为了tls
- match:
- gateways:
- mesh
port: 443
sniHosts:
- edition.cnn.com #基于SNI的路由
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 443
- match:
- gateways:
- istio-egressgateway
port: 443
sniHosts:
- edition.cnn.com #指定tls的SNI
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
EOF
由于TLS本身是加密的,无法像HTTP一样根据host首部字段进行路由管理,因此采用了SNI扩展。SNI位于TLS协商的client-hello阶段,作为client-hello的扩展字段存在,基于TLS SNI的路由与基于HTTP host首部字段的路由管理,在逻辑上是相同的。SNI也支持通配符模式。
访问https://edition.cnn.com/politics
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
HTTP/2 200
...
校验log
$ kubectl logs -l istio=egressgateway -n istio-system
...
[2020-06-02T09:06:43.152Z] "- - -" 0 - "-" "-" 906 1309129 1282 - "-" "-" "-" "-" "151.101.193.67:443" outbound|443||edition.cnn.com 10.83.1.219:39574 10.83.1.219:443 10.80.3.25:35492 edition.cnn.com -
$ kubectl delete serviceentry cnn
$ kubectl delete gateway istio-egressgateway
$ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-cnn
istio不能保证所有通过egress网关出去的流量的安全性,仅能保证通过sidecar代理的流量的安全性。如果攻击者绕过了sidecar代理,就可以不经过egress网关直接访问外部服务。此时,攻击者的行为不受istio的控制和监控。集群管理员或云供应商必须保证所有的流量都要经过egress网关。例如,集群管理员可以配置一个防火墙,拒绝所有非egress网关的流量。Kubernetes network policies也可以禁止所有非egress网关的流量。此外,集群管理员或云供应商可以配置网络来保证应用节点只能通过网关访问因特网,为了实现这种效果,需要阻止将公共IP分配给网关以外的pod,并配置NAT设备丢弃非egress网关的报文。
本节展示如何创建一个Kubernetes network policy来防止绕过egress网关。为了测试网络策略,需要创建一个命名空间test-egress
,部署sleep
应用,并尝试向网关安全的外部服务发送请求。
首先完成中的egress-gateway-for-https-traffic步骤,然后执行如下操作
创建test-egress
命名空间
$ kubectl create namespace test-egress
将sleep
部署到test-egress
命名空间中
$ kubectl apply -n test-egress -f samples/sleep/sleep.yaml
校验部署的pod不存在istio sidecar
$ kubectl get pod $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..Metadata.name}) -n test-egress
NAME READY STATUS RESTARTS AGE
sleep-f8cbf5b76-g2t2l 1/1 Running 0 27s
从 test-egress
命名空间中的sleep
pod向https://edition.cnn.com/politics 发送HTTPS请求,返回200成功
$ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..Metadata.name}) -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics
200
在istio组件所在的命名空间创建标签,如果istio组件部署在istio-system
命名空间中,则操作方式如下:
$ kubectl label namespace istio-system istio=system
给kube-system
命名空间打标签
$ kubectl label ns kube-system kube-system=true
部署一个NetworkPolicy
限制从test-egress
命名空间到istio-system
命名空间和kube-system
DNS服务的egress流量:
$ cat <<EOF | kubectl apply -n test-egress -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
Metadata:
name: allow-egress-to-istio-system-and-kube-dns
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kube-system: "true"
ports:
- protocol: UDP
port: 53
- to:
- namespaceSelector:
matchLabels:
istio: system
EOF
重新发送HTTPS请求到https://edition.cnn.com/politics,此时由于network policy阻止了流量,请求会失败。由于sleep
Pod无法绕过istio-egressgateway
(需要环境保证,如果环境上即使没有istio-egressgateway
也能访问外部服务,则此处可能会与预期不一样,本人使用的openshift环境无法测试这种场景)访问外部服务,唯一的方式是将流量定向到istio-egressgateway
上。
$ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..Metadata.name}) -n test-egress -c sleep -- curl -v https://edition.cnn.com/politics
Hostname was NOT found in DNS cache
Trying 151.101.65.67...
Trying 2a04:4e42:200::323...
Immediate connect fail for 2a04:4e42:200::323: Cannot assign requested address
Trying 2a04:4e42:400::323...
Immediate connect fail for 2a04:4e42:400::323: Cannot assign requested address
Trying 2a04:4e42:600::323...
Immediate connect fail for 2a04:4e42:600::323: Cannot assign requested address
Trying 2a04:4e42::323...
Immediate connect fail for 2a04:4e42::323: Cannot assign requested address
connect to 151.101.65.67 port 443 Failed: Connection timed out
现在给test-egress
命名空间的sleep
pod注入istio sidecar代理
$ kubectl label namespace test-egress istio-injection=enabled
重新在test-egress
命名空间中部署sleep
deployment
openshift环境需要首先执行如下步骤:
$ cat <<EOF | oc -n test-egress create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
Metadata:
name: istio-cni
EOF
$ oc adm policy add-scc-to-group privileged system:serviceaccounts:test-egress
$ oc adm policy add-scc-to-group anyuid system:serviceaccounts:test-egress
部署sleep
应用
$ kubectl delete deployment sleep -n test-egress
$ kubectl apply -f samples/sleep/sleep.yaml -n test-egress
校验test-egress
命名空间的sleep注入了istio sidecar
$ kubectl get pod $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..Metadata.name}) -n test-egress -o jsonpath='{.spec.containers[*].name}'
sleep istio-proxy
创建与default
命名空间中相同的destination rule,将流量定向到egress网关:
$ kubectl apply -n test-egress -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local #内部服务地址,不需要用serviceEntry
subsets:
- name: cnn
EOF
发送HTTPS请求到https://edition.cnn.com/politics:
$ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..Metadata.name}) -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics
校验egress网关代理的日志
$ kubectl logs -l istio=egressgateway -n istio-system
...
[2020-06-02T09:04:11.239Z] "- - -" 0 - "-" "-" 906 1309030 1606 - "-" "-" "-" "-" "151.101.1.67:443" outbound|443||edition.cnn.com 10.83.1.219:56116 10.83.1.219:443 10.80.3.25:59032 edition.cnn.com -
$ kubectl delete -f samples/sleep/sleep.yaml -n test-egress
$ kubectl delete destinationrule egressgateway-for-cnn -n test-egress
$ kubectl delete networkpolicy allow-egress-to-istio-system-and-kube-dns -n test-egress
$ kubectl label namespace kube-system kube-system-
$ kubectl label namespace istio-system istio-
$ kubectl delete namespace test-egress
在上一节的HTTPS流量的egress gateway中展示了如何配置istio来实现对外部服务的流量发起TLS。HTTP流量的egress网关中展示例子展示了如何配置istio来通过一个特定的egress网格服务来转发egress流量。本节的例子将结合这两个例子来描述如何配置一个egress网关来为到外部服务的流量发起TLS。
在default(已启用sidecar自动注入)命名空间下安装sleep
$ kubectl apply -f samples/sleep/sleep.yaml
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
创建egress网关
$ istioctl install -f cni-annotations.yaml --set values.global.istioNamespace=istio-system --set values.gateways.istio-egressgateway.enabled=true --set meshConfig.accessLogFile="/dev/stdout"
本节描述如何使用于HTTPS流量的egress gateway相同的方式发起TLS,但此处使用了一个egress网关。注意这种情况下,通过egress网关来发起TLS,而前面的例子中使用了sidecar发起TLS(curl时指定的是https://edition.cnn.com/politics)。
为edition.cnn.com
定义一个ServiceEntry
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: cnn
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
EOF
校验可以通过创建的ServiceEntry
向http://edition.cnn.com/politics发送请求
# kubectl exec "${SOURCE_POD}" -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 301 Moved Permanently
...
location: https://edition.cnn.com/politics
...
为edition.cnn.com
创建一个Gateway
,监听edition.cnn.com:80
,以及一个destination rule来处理sidecar到egress网关的请求
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers: #配置网关暴露的主机信息
- port:
number: 80
name: https-port-for-tls-origination
protocol: HTTPS
hosts:
- edition.cnn.com
tls:
mode: ISTIO_MUTUAL #与网关的连接使用ISTIO_MUTUAL模式
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings: #基于单个端口的流量策略
- port:
number: 80
tls: #与上游服务的连接设置,即到网关的tls配置,使用ISTIO_MUTUAL模式
mode: ISTIO_MUTUAL
sni: edition.cnn.com #表示TLS连接的服务端
EOF
定义一个VirtualService
将流量转移到egress网关,以及一个DestinationRule
来为到edition.cnn.com
的请求发起TLS。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways: #处理来自网格内部所有到edition.cnn.com的流量,发送到egress网关,并使用subset: cnn进行处理
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 80
weight: 100
- match:
- gateways:
- istio-egressgateway #处理来自网关istio-egressgateway的流量,直接发往edition.cnn.com
port: 80
route:
- destination:
host: edition.cnn.com
port:
number: 443
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: originate-tls-for-edition-cnn-com
spec:
host: edition.cnn.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # 网关到edition.cnn.com使用SIMPLE模式,由于edition.cnn.com是网格外部服务,因此不能使用ISTIO_MUTUAL
EOF
整个过程为:网格内部HTTP流量->istio-egressgateway(配置TLS)->发起TLS连接
发送HTTP
请求到http://edition.cnn.com/politics
# kubectl exec "${SOURCE_POD}" -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics
HTTP/1.1 200 OK
校验istio-egressgateway
pod的日志
$ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail
可以看到如下输出:
[2020-08-25T15:16:17.840Z] "GET /politics HTTP/2" 200 - "-" "-" 0 1297688 7518 460 "10.80.3.231" "curl/7.64.0" "2c71707e-3304-418c-840e-c37256c1ad41" "edition.cnn.com" "151.101.193.67:443" outbound|443||edition.cnn.com 10.80.3.232:38522 10.80.3.232:8080 10.80.3.231:46064 edition.cnn.com -
各种资源的tls设置:
资源 描述 virtualService tls字段:用于非终结TLS&HTTPS流量的路由规则。通常使用ClientHello消息中的SNI值进行路由。TLS路由将会应用于端口名为 https -
tls-
的平台服务,使用HTTPS/TLS协议的非终结网关端口(使用passthrough
TLS模式),以及使用HTTPS/TLS协议的serviceEntry端口。注:不关联virtual service的https-
或tls-
端口的流量将被视为不透明的TCP流量。DestinationRule DestinationRule主要对连接上游服务的tls进行配置,包含网格内的网关以及网格外的服务
ClientTLSSettings字段:连接上游的SSL/TLS相关设置
portLevelSettings字段:按照端口对上游服务进行设置,该字段包含了ClientTLSSettings字段Gateway Gateway主要暴露的服务的tls进行配置,含ingress和egress,前者通常可以使用SIMPLE/MUTUAL模式,后者可以使用SIMPLE/MUTUAL/ISTIO_MUTUAL模式。ServerTLSSettings字段:控制服务端行为的TLS相关选项集。使用这些选项来控制是否应将所有http请求重定向到https,并使用TLS模式
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule originate-tls-for-edition-cnn-com
$ kubectl delete destinationrule egressgateway-for-cnn
与前面章节类似,本节描述如何配置egress网关来向外部服务发起TLS,不同的是这次要使用mutual TLS(上面用的是SIMPLE模式)。
在本例中首先需要:
然后就是通过egress 网关发起TLS。
创建根证书和私钥,用于签发服务证书
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt
为 my-Nginx.mesh-external.svc.cluster.local
创建证书和私钥
$ openssl req -out my-Nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-Nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-Nginx.mesh-external.svc.cluster.local/O=some organization"
$ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-Nginx.mesh-external.svc.cluster.local.csr -out my-Nginx.mesh-external.svc.cluster.local.crt
生成client证书和私钥
$ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization"
$ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt
为了模拟一个支持mutual TLS协议的外部服务,需要在kubernetes集群中部署一个Nginx服务,但该服务位于istio服务网格外,即位于一个没有启用istio sidecar代理注入的命名空间。
创建一个唯一istio网格外的命名空间,名为mesh-external
,该命名空间不启用sidecar自动注入。
$ kubectl create namespace mesh-external
创建kubernetes secret,包含服务端的证书和CA证书
$ kubectl create -n mesh-external secret tls Nginx-server-certs --key my-Nginx.mesh-external.svc.cluster.local.key --cert my-Nginx.mesh-external.svc.cluster.local.crt
$ kubectl create -n mesh-external secret generic Nginx-ca-certs --from-file=example.com.crt
$ cat <<\EOF > ./Nginx.conf
events {
}
http {
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/Nginx/access.log main;
error_log /var/log/Nginx/error.log;
server {
listen 443 ssl;
root /usr/share/Nginx/html;
index index.html;
server_name my-Nginx.mesh-external.svc.cluster.local;
ssl_certificate /etc/Nginx-server-certs/tls.crt;
ssl_certificate_key /etc/Nginx-server-certs/tls.key;
ssl_client_certificate /etc/Nginx-ca-certs/example.com.crt;
ssl_verify_client on;
}
}
EOF
创建一个kubernetes ConfigMap来保存Nginx服务的配置信息
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
Metadata:
name: my-Nginx
namespace: mesh-external
labels:
run: my-Nginx
spec:
ports:
- port: 443
protocol: TCP
selector:
run: my-Nginx
---
apiVersion: apps/v1
kind: Deployment
Metadata:
name: my-Nginx
namespace: mesh-external
spec:
selector:
matchLabels:
run: my-Nginx
replicas: 1
template:
Metadata:
labels:
run: my-Nginx
spec:
containers:
- name: my-Nginx
image: Nginx
ports:
- containerPort: 443
volumeMounts:
- name: Nginx-config
mountPath: /etc/Nginx
readOnly: true
- name: Nginx-server-certs
mountPath: /etc/Nginx-server-certs
readOnly: true
- name: Nginx-ca-certs
mountPath: /etc/Nginx-ca-certs
readOnly: true
volumes:
- name: Nginx-config
configMap:
name: Nginx-configmap
- name: Nginx-server-certs
secret:
secretName: Nginx-server-certs
- name: Nginx-ca-certs
secret:
secretName: Nginx-ca-certs
EOF
创建kubernetes secret,包含客户端证书和CA证书
$ kubectl create -n istio-system secret tls Nginx-client-certs --key client.example.com.key --cert client.example.com.crt
$ kubectl create -n istio-system secret generic Nginx-ca-certs --from-file=example.com.crt
更新istio-egressgateway
deployment来挂载创建的secret。创建如下gateway-patch.json
文件来给istio-egressgateway
deployment打补丁。
cat > gateway-patch.json <<EOF
[{
"op": "add","path": "/spec/template/spec/containers/0/volumeMounts/0","value": {
"mountPath": "/etc/istio/Nginx-client-certs","name": "Nginx-client-certs","readOnly": true
}
},{
"op": "add","path": "/spec/template/spec/volumes/0","value": {
"name": "Nginx-client-certs","secret": {
"secretName": "Nginx-client-certs","optional": true
}
}
},"path": "/spec/template/spec/containers/0/volumeMounts/1","value": {
"mountPath": "/etc/istio/Nginx-ca-certs","name": "Nginx-ca-certs","path": "/spec/template/spec/volumes/1","value": {
"name": "Nginx-ca-certs","secret": {
"secretName": "Nginx-ca-certs","optional": true
}
}
}]
EOF
使用如下命令使补丁生效
$ kubectl -n istio-system patch --type=json deploy istio-egressgateway -p "$(cat gateway-patch.json)"
校验加载到istio-egressgateway
pod中的密钥和证书
$ kubectl exec -n istio-system "$(kubectl -n istio-system get pods -l istio=egressgateway -o jsonpath='{.items[0].Metadata.name}')" -- ls -al /etc/istio/Nginx-client-certs /etc/istio/Nginx-ca-certs
tls.crt
和tls.key
应该位于 /etc/istio/Nginx-client-certs
目录中,而 ca-chain.cert.pem
位于/etc/istio/Nginx-ca-certs
目录中。
为my-Nginx.mesh-external.svc.cluster.local:443
创建一个egress Gateway,以及destination rules和virtual service来将流量转发到egress网关上,并通过该egress网关转发给外部服务。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- my-Nginx.mesh-external.svc.cluster.local #暴露给网格内部服务地址,使用ISTIO_MUTUAL进行交互
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule #处理网格内部pod到网关的流量
Metadata:
name: egressgateway-for-Nginx
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: Nginx
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings: #连接的上游服务属性
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
sni: my-Nginx.mesh-external.svc.cluster.local
EOF
定义一个VirtualService将流量转移到egress网关
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-Nginx-through-egress-gateway
spec:
hosts:
- my-Nginx.mesh-external.svc.cluster.local
gateways:
- istio-egressgateway
- mesh
http: #内部流量采用http协议,由网关进行mutual tls协商
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: Nginx
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: my-Nginx.mesh-external.svc.cluster.local #外部服务地址
port:
number: 443
weight: 100
EOF
添加一个DestinationRule
来发起TLS
$ kubectl apply -n istio-system -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule #处理网关到外部服务的流量
Metadata:
name: originate-mtls-for-Nginx
spec:
host: my-Nginx.mesh-external.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: MUTUAL #使用MUTUAL模式连接外部服务,证书位于网关pod中
clientCertificate: /etc/istio/Nginx-client-certs/tls.crt
privateKey: /etc/istio/Nginx-client-certs/tls.key
caCertificates: /etc/istio/Nginx-ca-certs/example.com.crt
sni: my-Nginx.mesh-external.svc.cluster.local
EOF
发送HTTP请求到http://my-Nginx.mesh-external.svc.cluster.local
:
$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})" -c sleep -- curl -s http://my-Nginx.mesh-external.svc.cluster.local
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Nginx!</title>
...
校验istio-egressgateway
pod的日志
# kubectl logs -l istio=egressgateway -n istio-system | grep 'my-Nginx.mesh-external.svc.cluster.local' | grep HTTP
[2020-08-26T08:26:15.054Z] "GET / HTTP/1.1" 200 - "-" "-" 0 612 4 4 "10.80.3.231" "curl/7.64.0" "e8bf12bd-9c39-409e-a837-39afc151fc7e" "my-Nginx.mesh-external.svc.cluster.local" "10.80.2.14:443" outbound|443||my-Nginx.mesh-external.svc.cluster.local 10.80.2.15:56608 10.80.2.15:8443 10.80.3.231:50962 my-Nginx.mesh-external.svc.cluster.local -
$ kubectl delete secret Nginx-server-certs Nginx-ca-certs -n mesh-external
$ kubectl delete secret istio-egressgateway-certs istio-egressgateway-ca-certs -n istio-system
$ kubectl delete configmap Nginx-configmap -n mesh-external
$ kubectl delete service my-Nginx -n mesh-external
$ kubectl delete deployment my-Nginx -n mesh-external
$ kubectl delete namespace mesh-external
$ kubectl delete gateway istio-egressgateway
$ kubectl delete virtualservice direct-Nginx-through-egress-gateway
$ kubectl delete destinationrule -n istio-system originate-mtls-for-Nginx
$ kubectl delete destinationrule egressgateway-for-Nginx
$ rm example.com.crt example.com.key my-Nginx.mesh-external.svc.cluster.local.crt my-Nginx.mesh-external.svc.cluster.local.key my-Nginx.mesh-external.svc.cluster.local.csr client.example.com.crt client.example.com.csr client.example.com.key
$ rm ./Nginx.conf
$ rm ./gateway-patch.json
$ kubectl delete service sleep
$ kubectl delete deployment sleep
本节展示如何通过配置一个egress网关来为到外部服务的流量发起TLS。使用Secret Discovery Service (SDS)来配置私钥,服务证书以及根证书(上一节中使用文件挂载方式来管理证书)。
部署sleep应用,并获取其Pod名
$ kubectl apply -f samples/sleep/sleep.yaml
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
创建根证书和私钥来签署服务的证书
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt
为 my-Nginx.mesh-external.svc.cluster.local
创建证书和私钥
$ openssl req -out my-Nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-Nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-Nginx.mesh-external.svc.cluster.local/O=some organization"
$ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-Nginx.mesh-external.svc.cluster.local.csr -out my-Nginx.mesh-external.svc.cluster.local.crt
创建istio网格外的命名空间mesh-external
$ kubectl create namespace mesh-external
创建kubernetes secret来保存服务的证书和CA证书
$ kubectl create -n mesh-external secret tls Nginx-server-certs --key my-Nginx.mesh-external.svc.cluster.local.key --cert my-Nginx.mesh-external.svc.cluster.local.crt
$ kubectl create -n mesh-external secret generic Nginx-ca-certs --from-file=example.com.crt
$ cat <<\EOF > ./Nginx.conf
events {
}
http {
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/Nginx/access.log main;
error_log /var/log/Nginx/error.log;
server {
listen 443 ssl;
root /usr/share/Nginx/html;
index index.html;
server_name my-Nginx.mesh-external.svc.cluster.local;
ssl_certificate /etc/Nginx-server-certs/tls.crt;
ssl_certificate_key /etc/Nginx-server-certs/tls.key;
ssl_client_certificate /etc/Nginx-ca-certs/example.com.crt;
ssl_verify_client off; # simple TLS下server不需要校验client的证书
}
}
EOF
创建一个kubernetes ConfigMap来保存Nginx服务的配置信息
$ kubectl create configmap Nginx-configmap -n mesh-external --from-file=Nginx.conf=./Nginx.conf
部署Nginx服务
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
Metadata:
name: my-Nginx
namespace: mesh-external
labels:
run: my-Nginx
spec:
ports:
- port: 443
protocol: TCP
selector:
run: my-Nginx
---
apiVersion: apps/v1
kind: Deployment
Metadata:
name: my-Nginx
namespace: mesh-external
spec:
selector:
matchLabels:
run: my-Nginx
replicas: 1
template:
Metadata:
labels:
run: my-Nginx
spec:
containers:
- name: my-Nginx
image: Nginx
ports:
- containerPort: 443
volumeMounts:
- name: Nginx-config
mountPath: /etc/Nginx
readOnly: true
- name: Nginx-server-certs
mountPath: /etc/Nginx-server-certs
readOnly: true
- name: Nginx-ca-certs
mountPath: /etc/Nginx-ca-certs
readOnly: true
volumes:
- name: Nginx-config
configMap:
name: Nginx-configmap
- name: Nginx-server-certs
secret:
secretName: Nginx-server-certs
- name: Nginx-ca-certs
secret:
secretName: Nginx-ca-certs
EOF
创建一个kubernetes Secret来保存egress网格发起TLS使用的CA证书,由于使用的是SIMPLE模式,因此无需客户端证书,仅对ca证书实现SDS,后续在网关的destinationRule中使用。
$ kubectl create secret generic client-credential-cacert --from-file=ca.crt=example.com.crt -n istio-system
注意,Istio-only-CA证书的secret名称必须以-cacert结尾,并且必须在与部署的Istio相同的命名空间(默认为Istio-system
)中创建该secret。
secret名称不应该以
istio
或prometheus
开头,且secret不能包含token
字段
下面的配置除最后一个destinationRule外,其余配置都与上一节相同
为my-Nginx.mesh-external.svc.cluster.local:443
创建一个egress Gateway,以及destination rules和virtual service来将流量转发到egress网关上,并通过该egress网关转发给外部服务。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- my-Nginx.mesh-external.svc.cluster.local
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-Nginx
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: Nginx
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
sni: my-Nginx.mesh-external.svc.cluster.local
EOF
定义一个VirtualService将流量转移到egress网关
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-Nginx-through-egress-gateway
spec:
hosts:
- my-Nginx.mesh-external.svc.cluster.local
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: Nginx
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: my-Nginx.mesh-external.svc.cluster.local
port:
number: 443
weight: 100
EOF
添加一个DestinationRule
来发起TLS
$ kubectl apply -n istio-system -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: originate-tls-for-Nginx
spec:
host: my-Nginx.mesh-external.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE
credentialName: client-credential # 对应前面创建的包含ca证书的secret client-credential-cacert,但此时不带"-cacert"后缀
sni: my-Nginx.mesh-external.svc.cluster.local #网格外部服务
EOF
发送一个HTTP请求到 http://my-Nginx.mesh-external.svc.cluster.local
:
$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})" -c sleep -- curl -s http://my-Nginx.mesh-external.svc.cluster.local
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Nginx!</title>
...
检查istio-egressgateway
中的访问日志
# kubectl logs -l istio=egressgateway -n istio-system | grep 'my-Nginx.mesh-external.svc.cluster.local' | grep HTTP
[2020-08-26T12:26:09.316Z] "GET / HTTP/1.1" 200 - "-" "-" 0 612 3 3 "10.80.3.231" "curl/7.64.0" "67803676-5617-4e12-a14a-5cef95ea2e87" "my-Nginx.mesh-external.svc.cluster.local" "10.80.2.19:443" outbound|443||my-Nginx.mesh-external.svc.cluster.local 10.80.2.15:40754 10.80.2.15:8443 10.80.3.231:57626 my-Nginx.mesh-external.svc.cluster.local -
$ kubectl delete destinationrule originate-tls-for-Nginx -n istio-system
$ kubectl delete virtualservice direct-Nginx-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-Nginx
$ kubectl delete gateway istio-egressgateway
$ kubectl delete secret client-credential-cacert -n istio-system
$ kubectl delete service my-Nginx -n mesh-external
$ kubectl delete deployment my-Nginx -n mesh-external
$ kubectl delete configmap Nginx-configmap -n mesh-external
$ kubectl delete secret Nginx-server-certs Nginx-ca-certs -n mesh-external
$ kubectl delete namespace mesh-external
$ rm example.com.crt example.com.key my-Nginx.mesh-external.svc.cluster.local.crt my-Nginx.mesh-external.svc.cluster.local.key my-Nginx.mesh-external.svc.cluster.local.csr
$ rm ./Nginx.conf
下面操作跟前面一样,创建CA和客户端,服务端证书
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt
$ openssl req -out my-Nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-Nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-Nginx.mesh-external.svc.cluster.local/O=some organization"
$ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-Nginx.mesh-external.svc.cluster.local.csr -out my-Nginx.mesh-external.svc.cluster.local.crt
$ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization"
$ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt
下面的配置也跟之前一样
$ kubectl create namespace mesh-external
$ kubectl create -n mesh-external secret tls Nginx-server-certs --key my-Nginx.mesh-external.svc.cluster.local.key --cert my-Nginx.mesh-external.svc.cluster.local.crt
$ kubectl create -n mesh-external secret generic Nginx-ca-certs --from-file=example.com.crt
$ cat <<\EOF > ./Nginx.conf
events {
}
http {
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/Nginx/access.log main;
error_log /var/log/Nginx/error.log;
server {
listen 443 ssl;
root /usr/share/Nginx/html;
index index.html;
server_name my-Nginx.mesh-external.svc.cluster.local;
ssl_certificate /etc/Nginx-server-certs/tls.crt;
ssl_certificate_key /etc/Nginx-server-certs/tls.key;
ssl_client_certificate /etc/Nginx-ca-certs/example.com.crt;
ssl_verify_client on; # mutual TLS下的server会校验client的证书
}
}
EOF
$ kubectl create configmap Nginx-configmap -n mesh-external --from-file=Nginx.conf=./Nginx.conf
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
Metadata:
name: my-Nginx
namespace: mesh-external
labels:
run: my-Nginx
spec:
ports:
- port: 443
protocol: TCP
selector:
run: my-Nginx
---
apiVersion: apps/v1
kind: Deployment
Metadata:
name: my-Nginx
namespace: mesh-external
spec:
selector:
matchLabels:
run: my-Nginx
replicas: 1
template:
Metadata:
labels:
run: my-Nginx
spec:
containers:
- name: my-Nginx
image: Nginx
ports:
- containerPort: 443
volumeMounts:
- name: Nginx-config
mountPath: /etc/Nginx
readOnly: true
- name: Nginx-server-certs
mountPath: /etc/Nginx-server-certs
readOnly: true
- name: Nginx-ca-certs
mountPath: /etc/Nginx-ca-certs
readOnly: true
volumes:
- name: Nginx-config
configMap:
name: Nginx-configmap
- name: Nginx-server-certs
secret:
secretName: Nginx-server-certs
- name: Nginx-ca-certs
secret:
secretName: Nginx-ca-certs
EOF
创建一个kubernetes secret来保存客户端证书和ca证书
$ kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key \
--from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crt
使用SDS的secret名称跟上一节的要求一样,部署到istio所在的命名空间,且名称不能以istio
和prometheus
开头,不能包含token
字段。
为my-Nginx.mesh-external.svc.cluster.local:443
创建Gateway
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- my-Nginx.mesh-external.svc.cluster.local
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-Nginx
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: Nginx
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
sni: my-Nginx.mesh-external.svc.cluster.local
EOF
创建VirtualService
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-Nginx-through-egress-gateway
spec:
hosts:
- my-Nginx.mesh-external.svc.cluster.local
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: Nginx
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: my-Nginx.mesh-external.svc.cluster.local
port:
number: 443
weight: 100
EOF
与前面不同点就在该DestinationRule
中的credentialName
字段,包含了前面创建的证书client-credential
$ kubectl apply -n istio-system -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: originate-mtls-for-Nginx
spec:
host: my-Nginx.mesh-external.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: MUTUAL
credentialName: client-credential # this must match the secret created earlier to hold client certs
sni: my-Nginx.mesh-external.svc.cluster.local
EOF
发送请求并校验egressgateway pod的日志
$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})" -c sleep -- curl -s http://my-Nginx.mesh-external.svc.cluster.local
$ kubectl logs -l istio=egressgateway -n istio-system | grep 'my-Nginx.mesh-external.svc.cluster.local' | grep HTTP
$ kubectl delete secret Nginx-server-certs Nginx-ca-certs -n mesh-external
$ kubectl delete secret client-credential -n istio-system
$ kubectl delete configmap Nginx-configmap -n mesh-external
$ kubectl delete service my-Nginx -n mesh-external
$ kubectl delete deployment my-Nginx -n mesh-external
$ kubectl delete namespace mesh-external
$ kubectl delete gateway istio-egressgateway
$ kubectl delete virtualservice direct-Nginx-through-egress-gateway
$ kubectl delete destinationrule -n istio-system originate-mtls-for-Nginx
$ kubectl delete destinationrule egressgateway-for-Nginx
$ rm example.com.crt example.com.key my-Nginx.mesh-external.svc.cluster.local.crt my-Nginx.mesh-external.svc.cluster.local.key my-Nginx.mesh-external.svc.cluster.local.csr client.example.com.crt client.example.com.csr client.example.com.key
$ rm ./Nginx.conf
$ rm ./gateway-patch.json
$ kubectl delete service sleep
$ kubectl delete deployment sleep
上两节中为网关配置了特定的主机名,如 edition.cnn.com
。本节将展示如何为egress流量配置位于同域的一组主机,如*.wikipedia.org
。
假设要在istio上为所有语言的wikipedia.org
站点启用egress流量,每个特定语言的wikipedia.org
站点都有其各自的主机名,如en.wikipedia.org
和de.wikipedia.org
分别表示英文和德文。此时可能会希望为所有的Wikipedia egress流量配置相同的参数,而不需要为每种语言的站点单独指定。
重新安装Istio,使用--set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY
默认阻塞出站流量
# istioctl install -f cni-annotations.yaml --set values.global.istioNamespace=istio-system --set values.gateways.istio-egressgateway.enabled=true --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY --set meshConfig.accessLogFile="/dev/stdout"
$ kubectl apply -f samples/sleep/sleep.yaml
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..Metadata.name})
首先,为了简化场景,创建一个带通配符主机的ServiceEntry
,并直接访问服务。当直接调用服务时(不经过egress网关),通配符主机的配置与其他主机并没有什么不同(只是对同一域中的主机的服务更加方便)。
为*.baidu.com
定义一个ServiceEntry
和相应的VirtualSevice
:
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: baidu
spec:
hosts:
- "*.baidu.com" #通配符主机
ports:
- number: 443
name: tls
protocol: TLS #HTTPS也是可以的
EOF
发送请求给https://map.baidu.com/和https://fanyi.baidu.com/:
# kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -s https://map.baidu.com/ | grep -o "<title>.*</title>"; curl -s https://fanyi.baidu.com/ | grep -o "<title>.*</title>"'
<title>百度地图</title>
<title>百度翻译-200种语言互译、沟通全世界!</title>
$ kubectl delete serviceentry baidu
通过egress网关访问通配符主机的配置取决于通配符域集是否由一个公共主机来提供服务。例如*.wikipedia.org,所有指定语言的站点都由*wikipedia.org的某一个服务端提供服务,这样就可以将流量路由到任何*.wikipedia.org站点对应的IP(包括www.wikipedia.org)。
由于map.baidu.com和fanyi.baidu.com的服务并不是由www.baidu.com对应的某个IP服务的(可以使用
nslookup
或dig
命令查看),因此无法用于测试本场景,下面为官网内容。
一般情况下,如果一个通配符的所有域名不是由一个托管服务器提供服务的,则需要更复杂的配置。
当一个服务端服务所有的通配符主机时,对使用egress网关访问通配符主机的配置与访问非通配符主机的配置类似。
为*.wikipedia.org,
创建一个egress Gateway
,destination rule和一个virtual service,将流量导入egress网关,并通过egress网关访问外部服务
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- "*.wikipedia.org"
tls:
mode: PASSTHROUGH #由网格内部发起https请求,非终结TLS
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-wikipedia
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: wikipedia
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-wikipedia-through-egress-gateway
spec:
hosts:
- "*.wikipedia.org"
gateways:
- mesh
- istio-egressgateway
tls: #网格内部的TLS流量处理
- match:
- gateways:
- mesh
port: 443
sniHosts:
- "*.wikipedia.org"
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: wikipedia
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
sniHosts:
- "*.wikipedia.org"
route:
- destination:
host: www.wikipedia.org #将流量从网格传给外部服务。由于www.wikipedia.org可以处理不同语言的请求,因此在下面才能在用curl请求不同语言的站点时正确返回结果。
port:
number: 443
weight: 100
EOF
为目的服务www.wikipedia.com创建ServiceEntry
。由于出站流量被--set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY
阻塞,因此需要配置ServiceEntry指定外部服务,这样也便于监控流量。
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: www-wikipedia
spec:
hosts:
- www.wikipedia.org
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS #支持DNS和静态IP
EOF
发送请求给https://map.baidu.com/和https://fanyi.baidu.com/:
$ kubectl exec "$SOURCE_POD" -c sleep -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o "<title>.*</title>"'
<title>Wikipedia,the free encyclopedia</title>
<title>Wikipedia – Die freie Enzyklopädie</title>
校验egress gateway的日志
$ kubectl exec "$(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].Metadata.name}')" -c istio-proxy -n istio-system -- pilot-agent request GET clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
outbound|443||www.wikipedia.org::208.80.154.224:443::cx_total::2
$ kubectl delete serviceentry www-wikipedia
$ kubectl delete gateway istio-egressgateway
$ kubectl delete virtualservice direct-wikipedia-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-wikipedia
上一节中的配置之所以能够生效,是因为任何一个wikipedia.org服务端都可以服务所有的*.wikipedia.org站点。但情况不总是这样的,例如有可能希望访问更加通用的域,如.com
或.org
。
在istio网关上配置到任意通配符的域会带来挑战,上一节中直接将流量传递给了 www.wikipedia.org(直接配置到了网关上)。受限于Envoy(默认的istio egress网关代理),网关并不知道接收到的请求中的任意主机的IP地址。Envoy会将流量路由到预定义的主机,预定义的IP地址或请求中的原始目的IP地址。在网关场景下,由于请求会首先被路由到egress网关上,因此会丢失请求中的原始目的IP地址,并将目的IP地址替换为网关的IP地址,最终会导致基于Envoy的istio网关无法路由到没有进行预配置的任意主机,进而导致无法为任意通配符域执行流量控制。
为了给HTTPS和TLS启用流量控制,需要额外部署一个SNI转发代理。Envoy会将到通配符域的请求路由到SNI转发代理,然后将请求转发到SNI中指定的目的地。
使用SNI代理和相关组件的egress网关架构如下,由于Envoy无法处理任意通配符的主机,因此需要转发到SNI代理上进行SNI的路由处理。
下面将展示如何重新部署egress网关来使用SNI代理,并配置istio通过网关路由HTTPS流量到任意通配符域。
本节中将在标准的istio Envoy代理之外部署为egress网关部署一个SNI代理。本例中使用Nginx作为SNI代理,该SNI代理将会监听8443端口,然后将流量转发到443端口。
为Nginx SNI代理创建配置文件。注意server
下的listen
指令指定了端口8443
,proxy_pass
指令使用ssl_preread_server_name
,端口443
以及将ssl_preread
设置为on
来启用SNI
reading。
$ cat <<EOF > ./sni-proxy.conf
user www-data;
events {
}
stream {
log_format log_stream '\$remote_addr [\$time_local] \$protocol [\$ssl_preread_server_name]'
'\$status \$bytes_sent \$bytes_received \$session_time';
access_log /var/log/Nginx/access.log log_stream;
error_log /var/log/Nginx/error.log;
# tcp forward proxy by SNI
server {
resolver 8.8.8.8 ipv6=off;
listen 127.0.0.1:8443;
proxy_pass \$ssl_preread_server_name:443;
ssl_preread on;
}
}
EOF
创建一个kubernets ConfigMap来保存Nginx SNI代理的配置:
$ kubectl create configmap egress-sni-proxy-configmap -n istio-system --from-file=Nginx.conf=./sni-proxy.conf
创建一个IstioOperator
CR来添加带SNI代理的新的egress网关。
# cat egressgateway-with-sni-proxy.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
egressGateways:
- name: istio-egressgateway-with-sni-proxy
enabled: true
label:
app: istio-egressgateway-with-sni-proxy
istio: egressgateway-with-sni-proxy
k8s:
service:
ports:
- port: 443
name: https
cni:
enabled: true
namespace: kube-system
values:
meshConfig:
certificates:
- secretName: dns.example1-service-account
dnsNames: [example1.istio-system.svc,example1.istio-system]
- secretName: dns.example2-service-account
dnsNames: [example2.istio-system.svc,example2.istio-system]
cni:
excludeNamespaces:
- istio-system
- kube-system
chained: false
cniBinDir: /var/lib/cni/bin
cniConfDir: /etc/cni/multus/net.d
cniConfFileName: istio-cni.conf
sidecarInjectorWebhook:
injectedAnnotations:
"k8s.v1.cni.cncf.io/networks": istio-cni
部署新的网关
# istioctl install -f egressgateway-with-sni-proxy.yaml --set values.global.istioNamespace=istio-system --set values.gateways.istio-egressgateway.enabled=true --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY --set meshConfig.accessLogFile="/dev/stdout" --set values.gateways.istio-egressgateway.runAsRoot=true
给Pod istio-egressgateway-with-sni-proxy
patch一个SNI代理容器
$ cat <<EOF > ./egressgateway-with-sni-proxy-patch.yaml
spec:
template:
spec:
volumes:
- name: sni-proxy-config
configMap:
name: egress-sni-proxy-configmap
defaultMode: 292 # 0444
containers:
- name: sni-proxy
image: Nginx
volumeMounts:
- name: sni-proxy-config
mountPath: /etc/Nginx
readOnly: true
securityContext:
runAsNonRoot: false
runAsUser: 0
EOF
# kubectl patch deployment istio-egressgateway-with-sni-proxy -n istio-system --patch "$(cat ./egressgateway-with-sni-proxy-patch.yaml)"
deployment.extensions/istio-egressgateway-with-sni-proxy patched
校验新的egress网关已经在运行,且该pod有2个容器(一个是Envoy代理,另一个是SNI代理)
# kubectl get pod -l istio=egressgateway-with-sni-proxy -n istio-system
NAME READY STATUS RESTARTS AGE
istio-egressgateway-with-sni-proxy-b79df9c8c-brfbw 2/2 Running 0 2m4s
创建一个service entry,静态地址为127.0.0.1,并禁用mutual TLS。
# kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: sni-proxy
spec:
hosts:
- sni-proxy.local
location: MESH_EXTERNAL #将SNI代理设置为外部服务,不启用mTLS
ports:
- number: 8443
name: tcp
protocol: TCP
resolution: STATIC
endpoints:
- address: 127.0.0.1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: disable-mtls-for-sni-proxy
spec:
host: sni-proxy.local #配置到sni-proxy.local的规则,禁用mTLS
trafficPolicy:
tls:
mode: DISABLE
EOF
为*.baidu.com
定义一个ServiceEntry
$ cat <<EOF | kubectl create -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
Metadata:
name: baidu
spec:
hosts:
- "*.baidu.com"
ports:
- number: 443
name: tls
protocol: TLS
EOF
为 *.baidu.com,端口443创建一个egress Gateway
,以及virtual service将流量通过网关导入*.baidu.com
# kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
Metadata:
name: istio-egressgateway-with-sni-proxy
spec:
selector:
istio: egressgateway-with-sni-proxy
servers: #配置监听"*.baidu.com",并启用mTLS
- port:
number: 443
name: tls-egress
protocol: TLS
hosts:
- "*.baidu.com"
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
Metadata:
name: egressgateway-for-baidu
spec:
host: istio-egressgateway-with-sni-proxy.istio-system.svc.cluster.local #配置在端口443上启用mTLS
subsets:
- name: baidu
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
Metadata:
name: direct-baidu-through-egress-gateway
spec:
hosts:
- "*.baidu.com"
gateways:
- mesh
- istio-egressgateway-with-sni-proxy
tls:
- match: #将网格内部发往"*.baidu.com:443"的流量定向到istio-egressgateway-with-sni-proxy.istio-system.svc.cluster.local:443
- gateways:
- mesh
port: 443
sniHosts:
- "*.baidu.com"
route:
- destination:
host: istio-egressgateway-with-sni-proxy.istio-system.svc.cluster.local
subset: baidu
port:
number: 443
weight: 100
tcp:
- match: #将网关istio-egressgateway-with-sni-proxy上443端口的流量定向到sni-proxy.local:8443
- gateways:
- istio-egressgateway-with-sni-proxy
port: 443
route:
- destination:
host: sni-proxy.local
port:
number: 8443
weight: 100
---
# The following filter is used to forward the original SNI (sent by the application) as the SNI of the
# mutual TLS connection.
# The forwarded SNI will be will be used to enforce policies based on the original SNI value.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
Metadata:
name: forward-downstream-sni
spec:
configPatches:
- applyTo: NETWORK_FILTER
match:
context: SIDECAR_OUTBOUND
listener:
portNumber: 443
filterChain:
filter:
name: istio.stats
patch:
operation: INSERT_BEFORE
value:
name: forward_downstream_sni
config: {}
EOF
给网关添加一个EnvoyFilter,防止欺骗
# kubectl apply -n istio-system -f - <<EOF
# The following filter verifies that the SNI of the mutual TLS connection is
# identical to the original SNI issued by the client (the SNI used for routing by the SNI proxy).
# The filter prevents the gateway from being deceived by a malicIoUs client: routing to one SNI while
# reporting some other value of SNI. If the original SNI does not match the SNI of the mutual TLS connection,# the filter will block the connection to the external service.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
Metadata:
name: egress-gateway-sni-verifier
spec:
workloadSelector:
labels:
app: istio-egressgateway-with-sni-proxy
configPatches:
- applyTo: NETWORK_FILTER
match:
context: GATEWAY
listener:
portNumber: 443
filterChain:
filter:
name: istio.stats
patch:
operation: INSERT_BEFORE
value:
name: sni_verifier
config: {}
EOF
发送HTTPS请求到 https://map.baidu.com和https